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INTRODUCTION 


The 16C32 Integrated Universal Serial Controller 
(USC) is the latest member of Zilog's large and 
popular family of multi-protocol serial controllers, which 
ranges from the original Z80-SIO through the industry- 
standard SCC and the more recent ESCC, ISCC, 
USC, and MUSC. Compared to the SCC family and 
most competing devices, the USC family features 
more serial protocols, a 16-data bus, higher data 
rates, larger FIFOs, better support for DMA operation, 
and more convenient software handling. The IUSC 
adds a Direct Memory Access (DMA) facility that has 
correspondingly powerful capabilities for transferring 
data to and from data buffers in memory. 


FEATURES 


* Full-duplex muiti-protocol serial controller 

* Two multi-mode DMA channels with peak transfer 

rates up to 13.33 MBytes/sec 

Serlal data rates to 20M bits/second 

Serial modes Include Asynchronous, Synchronous, 

SDLC, HDLC, Ethernet, 1553B, and Nine-Bit 

* Two baud rate generators 

Digital phase locked loop for clock recovery 

Receive and Transmit Time Slot Assigners for ISDN 

and Fractional T1 applications 

Ten general purpose I/O lines plus Carrier Detect, 

Clear to Send, and two Clock I/O's 

Transmit and receive frame-length counters, 

independent of the DMA facility 

HDLC/SDLC features Include 8-bit address checking, 

loop mode, 16/32 bit CRC, programmable idle state, 

auto preamble option or programmable minimum 

Flag count between frames, real-time or In-data- 

stream Abort notification 

* Sync features include 2 to 16 bit sync pattern, sync- 

strip option, 16/32 bit CRC, programmable idle state, 

auto preamble option, X.21 xmit/rev slaving 

Async features Include false-start filtering, stop bit 

length programmable by 1/16-bit steps, parity 

generation/checking, break generation/detection 

32-character transmit and receive FIFOs between the 

serlal controller and the DMA channels 

Improved bus/serial interlocks prevent extra received 

DMA characters and misreporting of FIFO fill levels 

* DMA modes Include single buffer, pipelined, array 
chained, and Iinked-list 
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* 16-32 bit addressing, 8- or 16-bit data 


* Received frames can be placed In separate memory 
buffers or stored successively without regard for 
buffer boundaries 


Received-frame status can be stored with DMA 
control Info or after the end of each frame 


Transmit-frame control Info can come from the DMA 
control structure or before the start of each frame 


Buffer ring wraparound protection 

Programmable throttling of DMA bus occupancy 
Flexible adaptation to various system buses 
Flexible interrupt and bus-arbitration modes 
Interrupt and bus-acknowledge dalsy chains 
Socket- and software-compatible with Z16C31 IUSC 
High speed, low power CMOS technology 

68 pin PLCC 
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LOGIC SYMBOL 


CLK 
/RESET 
/CS 
D//C 
$//D 


WAIT//RDY 


/JINTACK 
IE! 
/ABORT 
/BIN 
/RxC 
[TxC 
RxD 
/CTS 
/DCD 
PORT7:0 


AD15:0 
/UAS 
/AS 

/DS 

/RD 
/WR 
R//W 
B//W 
/INT 
IEO 
/BUSREQ 
/BOUT 
/RxREQ 
/TxREQ 
TxD 
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PIN DESCRIPTIONS 


/RESET. Reset (input, active low). A low on this line 
places the IUSC in a known, inactive state, and 
conditions it so that the data, from the next write 
operation that asserts the /CS pin, goes into the Bus 
Configuration Register (BCR) regardless of register 
addressing. /RESET should be driven low as soon as 
possible during power-up, and as needed when 
restarting the overall system or the communications 
subsystem. 


CLK. System Clock (input). This signal is the timing 
reference for the DMA and bus interface logic. (The 
serial controller section is clocked by the selected 
sources of receive and transmit clocking.) 


AD15-0. Address/Data Bus (inputs/3-state outputs). 
After Reset, these lines carry data between the 
controlling microprocessor and the IUSC, and may 
also carry multiplexed addresses of registers within 
the IUSC. Such operation, between the host 
processor and the IUSC, is often called slave mode. 
Once the software has set up the device and placed it 
into operation, these lines also carry multiplexed 
addresses and data between the IUSC and system 
memory; such operation is called master mode. 
AD15-0 can be used in a variety of ways based on 
whether the IUSC senses activity on /AS after Reset, 
and on the data written to the Bus Configuration 
Register (BCR). 


/CS. Chip Select (input, active low). A low on this line 
indicates that the controlling microprocessor's current 
bus cycle refers to a register in the |IUSC. The IUSC 


ignores /CS when a low on /INTACK indicates that the 
current bus operation is an interrupt acknowledge 
cycle. On a multiplexed bus the IUSC latches the 
state of this pin at rising edges on /AS, while on a 
non-multiplexed bus it latches /CS at leading/falling 
edges on /DS, /RD, or /WR. 


S//D. Serial/DMA (input/3-state output, input high 
indicates serial"). Cycles with /CS low, and /INTACK 
and this pin both high, access registers in the serial 
controller section. Cycles with /INTACK high, and /CS 
and this pin both low, access registers in the DMA 
controller section. The state of this line when the Bus 
Configuration Register is written determines "wait vs. 
acknowledge" operation, as described in the text. On 
a multiplexed bus the IUSC latches the state of this 
pin at rising edges on /AS, while on a non-multiplexed 
bus it latches the state at leading/falling edges on /DS, 
/RD, or /WR. 


Software can program the IUSC so that when it is 
acting aS a bus master, it drives this line high to indi- 
cate a DMA cycle for serial data and low to indicate an 
"array" or "list" access. (Array/list accesses read the 
address and length of the next memory buffer.) 


D//C. Data/Control (input/3-state output, input high 
indicates Data). A slave read cycle with /CS low, and 
all three of /INTACK, S//D, and this pin high, fetches 
data from the serial controller's receive FIFO via the 
Receive Data Register (RDR). A slave write cycle 
with the same conditions writes data into the transmit 
FIFO via its Transmit Data Register (TDR). Slave 
cycles with /INTACK and S//D high, and /CS and this 
pin low, read or write registers in the serial controller. 
On a multiplexed bus the IUSC determines which 
register to access from the low-order AD lines at the 
rising edge of /AS. On a non-multiplexed bus it 
typically selects the register based on the LSBits of 
the serial controller's Channel Command / Address 
Register. On a multiplexed bus the IUSC latches the 
state of this pin at rising edges on /AS, while on a 
non-multiplexed bus it latches the state at leading/ 
falling edges on /DS, /RD, or /WR. 


For slave cycles on a multiplexed bus, with /INTACK 
high and both /CS and S//D low, the state of this line 
at the rising edge of /AS selects between the registers 
of the transmit DMA channel (low) and those of the 
receive DMA channel (high). On a non-multiplexed 
bus with /INTACK high and /CS and S//D both low, the 
IUSC can take the DMA channel selection from this 
line or from the DMA Command / Address Register. 


Software can program the IUSC so that when it is 
acting as a bus master, it drives this line high to indi- 
cate a DMA cycle for the receiver and low to indicate 
a cycle for the transmitter. 


/AS. Address Strobe (input/3-state output, active 
low). After a reset, the IUSC's bus interface logic 
monitors this signal to see if the host bus multiplexes 
addresses and data on AD15-0. If the logic sees 
activity on /AS before (or as) software writes the Bus 
Configuration Register, then in subsequent slave 
cycles directed to the IUSC, it captures register 
selection from the AD lines, S//D, and C//D on rising 
edges of /AS. 


When the IUSC takes control of the bus and operates 
as a master, it always uses the bus in a multiplexed 
fashion, driving /AS low when it places the least 
significant 16 bits of an address on the AD15-0 lines. 
External devices can be used to de-multiplex the ad- 
dress and data, if this is necessary to match the 
characteristics of the host processor or host bus. 


For a non-multiplexed bus this pin should be pulled up 
to +5V using a resistor of about 10 KOhms. If a pro- 
cessor uses a non-multiplexed bus, yet has an output 
called Address Strobe (e.g., 680x0 devices), this pin 
should not be tied to the output. 


/UAS. Upper Address Strobe (3-state output, active 
low). When the IUSC takes control of the bus and 
operates as a master, it drives /UAS low when it 
places the more significant 16 bits of an address on 
AD15-0. External memory and other slave device (or 
de-multiplexing latches) should capture the MS 
address at each rising edge on this line. 


R//W. Read / Write control (input/3-state output, low 
signifies "write"). R/MW and /DS indicate read and 
write cycles on the bus, for host processors / buses 
having this kind of signalling. When the IUSC has 
taken control of the bus and is operating in master 
mode, this pin is an output that remains valid 
throughout the low time of /DS. In slave cycles the 
l\USC samples R//W at each leading/falling edge on 
/DS. 


/DS. Data Strobe (input/3-state output, active low). 
R//W and /DS indicate read and write cycles on the 
bus, for host processors/buses having this kind of sig- 
nalling. It is an output when the IUSC has taken con- 
trol of the bus and is operating in master mode, 
otherwise it is an input that is qualified by /CS low or 
/INTACK low. In master mode the R//W line remains 
valid throughout the low time of this line. In slave 
mode the IUSC samples R//W at each leading/falling 
edge on this line. For slave write cycles and master 
read cycles, the IUSC captures data at the rising 
(trailing) edge on this line. For slave read cycles the 
lUSC provides valid data on the AD lines within the 
specified access time after this line goes low, and 
keeps the data valid until after the master releases 
this line to high. For master write cycles, the |IUSC 
places valid data on the AD lines before it drives this 


signal to low, and keeps the data valid until after it 
drives this line back to high. 


/RD. Read Strobe (input/3-state output, active low). 
This line indicates a read cycle on the bus, for host 
processors/buses having this kind of signalling. It is 
an output when the IUSC has taken control of the bus 
and is operating in master mode, otherwise it is an 
input that is qualified by /CS low or /INTACK low. For 
master read cycles, the IUSC captures data at the 
rising (trailing) edge of this line. For slave read cycles 
the IUSC provides valid data on the AD lines within 
the specified access time after this line goes low, and 
keeps the data valid until after the master releases 
this line to high. 


IWR. Write Strobe (input/3-state output, active low). 
This line indicates write cycles on the bus, for host 
processors/buses having this kind of signalling. It is 
an output when the IUSC has taken control of the bus 
and is operating in master mode, otherwise it is an 
input that is qualified by /CS low. For slave write 
cycles, the IUSC captures write data at the rising 
(trailing) edge of this line. For master write cycles, the 
IUSC places valid data on the AD lines before it drives 
this signal to low, and keeps the data valid until after it 
drives this line back to high. 


B/W. Byte / Word Select (3-state output, high indi- 
cates 8-bit transfer). When the IUSC takes control of 
the bus and operates as a master, a high on this line 
indicates that a byte is to be transferred, and a low 
indicates that 16 bits are to be transferred. The |IUSC 
ignores this signal during slave cycles: it takes the 
byte/word distinction from an AD line at the rising 
edge of /AS, or from a bit in the serial or DMA Com- 
mand/Address Register. 


/WAIT//RDY. Wait, Ready, or Acknowledge handa- 
shaking (input/3-state output, active low). The IUSC 
drives this line full-time after Reset, except that it 
releases the line to act as an input when it has taken 
control of the bus and is operating in master mode. In 
both directions, the line can carry "wait" or "acknow- 
ledge" signalling depending on the state of the S//D 
input during the initial BCR write. If S//D is high when 
the BCR is written, this line operates thereafter as a 
Ready/Wait line for Zilog and most Intel processors. 
In this mode the IUSC will not complete a master 
cycle while this line is low, and it asserts this line low 
until it's ready to complete an interrupt acknowledge 
cycle, but it never asserts this line when the host 
accesses one of the IUSC registers. 


lf S//D is low when the BCR is written, this line oper- 
ates thereafter as an Acknowledge line for Motorola 
and some Intel processors. In this mode the IUSC will 
not complete a master cycle until this line is low. It 
asserts this line low for register read and write cycles, 


and when it is ready to complete an interrupt acknow- 
ledge cycle. 


In any case /WAIT//RDY is a 3-state (not open-drain) 
output. The board designer can combine this signal 
with similar signals from other slaves, by means of an 
external logic gate or a 3-state or open-collector 
driver. 


INT. Interrupt Request (output, active low). The 
lIUSC drives this line low when (1) its IEI pin is high, 
(2) one or more of its interrupt condition(s) is (are) 
enabled and pending, and (3) the Under Service flag 
isn't set for its highest priority enabled/pending 
condition, nor for any higher-priority internal condition. 
Software can program whether the bus interface 
drives this pin in a totem-pole or an open-drain 
fashion. 


IINTACK. Interrupt Acknowledge (input, active low), 
A low on this line indicates that the host processor is 
performing an interrupt acknowledge cycle. In some 
systems a low on this line may further indicate that 
external logic has selected this IUSC as the device to 
be acknowledged, or as a potential device to be 
acknowledged. AQ field in the Bus Configuration 
Register selects whether this line carries a level- 
sensitive "status" signal that the |IUSC should sample 
at the leading edge of /AS or /DS, or a single-pulse or 
double-pulse protocol. The IUSC will respond to an 
interrupt acknowledge cycle in a variety of ways 
depending on this programming and the state of the 
/INT and {EI lines, as described in the text. 


lEl. /nterrupt Enable In (input, active high). This 
signal and the IEO pin can be part of an interrupt- 
acknowledge daisy-chain with other devices that may 
request interrupts. If IEl is high outside of an inter- 
rupt acknowledge cycle, one or more IUSC interrupt 
condition(s) is(are) enabled and pending, and the 
Under Service flag isn't set for the (highest priority 
such) condition nor for any higher-priority one, then 
the IUSC requests an interrupt by driving its /INT pin 
low. If the IEI pin is high during an interrupt acknow- 
ledge cycle, one or more IUSC interrupt condition(s) 
is(are) enabled and pending, and the Under Service 
flag isn't set for the (highest priority such) condition 
nor for any higher-priority one, then the IUSC keeps 
[EO low and responds to the cycle. 


IEO. /nterrupt Enable Out (output, active high). This 
signal and/or IEI can be part of an interrupt acknow- 
ledge daisy chain with other devices that may request 
interrupts. The IUSC drives its IEO pin low whenever 
its IEI pin is low, and/or if the Under Service flag is set 
for any condition. This IUSC drives this signal slightly 
differently during an interrupt acknowledge cycle, in 
that it also forces IEO low if it is (has been) requesting 
an interrupt. 


/BUSREQ. Bus Request (output, active low). The 
DMA controller section drives this line low to request 
control of the host bus. /BUSREQ can be an open- 
drain or totem-pole output depending on a bit in the 
Bus Configuration Register. In open-drain mode the 
IUSC samples the pin as an input and only drives it 
low after sampling it high. 


/BIN. Bus Acknowledge In (input, active low). When 
the IUSC receives a falling edge on this input, it 
samples whether it has been driving (or has just 
begun to drive) /BUSREQ. If so, it keeps /BOUT high 
and takes control of the host bus. If not, it "passes 
the bus grant" by driving /BOUT low. This signal can 
be used with /BOUT to form a bus-grant daisy chain 
for arbitration of bus control. Alternatively, it can be 
connected to a direct, positive grant from an external 
arbiter, and the /BOUT pin can be left unconnected. 


/BOUT. Bus Acknowledge Out (output, active low). 
As noted above, this signal can be used with /BIN to 
form a bus-grant daisy chain for arbitration of bus 
control. 


/ABORT. Abort Master Cycle (input, active low). A 
low on this line during a master cycle makes the cur- 
rently active DMA channel terminate its activity and 
enter a disabled state. Note that /ABORT is only 
effective during a DMA cycle, so that the |USC knows 
which channel should be "aborted". Also note that ex- 
ternal logic must set /WAIT//RDY to the right state for 
the cycle to complete, before /ABORT becomes 
effective. 


RxD. Received Data (input, positive logic). The serial 
input. 


TxD. Transmit Data (output, positive logic). The 
serial output. 


/RxC. Receive Clock (input or output). This signal 
can be used as a clock input for any of the functional 
blocks in the serial controller. Or, software can pro- 
gram the IUSC so that this pin is an output carrying 
any of several receiver or internal clock signals, a 
general purpose input or output, or an interrupt input. 


/TxC. Transmit Clock (input or output). This signal 
can be used as a clock input for any of the functional 
blocks in the serial controller. Or, software can pro- 
gram the IUSC so that this pin is an output carrying 
any of several transmitter or internal clock signals, a 
general purpose input or output, or an interrupt input. 


/RxREQ. Receive DMA Request (input or output). In 
device testing or in applications not using the serial 
and DMA controller sections together in the usual 
way, this pin can carry a low-active DMA Request 
from the receive FIFO. On the IUSC this request is 
internally routed to the on-chip Receive DMA channel, 


and it's more typical to use this pin as a general- 
purpose input or output or as an interrupt input. 


/TxREQ. Transmit DMA Request (input or output). In 
device testing or in applications not using the serial 
and DMA controller sections together in the usual 
way, this pin can carry a low-active DMA Request 
from the transmit FIFO. On the IUSC this request is 
internally routed to the on-chip Transmit DMA chan- 
nel, and it's more typical to use this pin as a general- 
purpose input or output or as an interrupt input. 


/DCD. Data Carrier Detect (input or output, active 
low). Software can program the IUSC so that this 
signal enables / disables the receiver. In addition or 
instead, software can program the device to request 
interrupts in response to transitions on this line. The 
pin can also be used as a simple input or output. 


/CTS. Clear to Send (input or output, active low). 
Software can program the IUSC so that this signal 
enables / disables the transmitter. In addition or 
instead, software can program the device to request 
interrupts in response to transitions on this line. The 
pin can also be used as a simple input or output. 


PORT7//TxComplete. General Purpose I/O or Trans- 
mit Complete (input or output). Software can 
program the IUSC so that this pin is a general 
purpose input or output, or so that it carries a 
Transmit Complete signal from the Transmitter, that 
can control an external driver on TxD. The IUSC 
captures transitions on this pin in internal latches, as 
described in the text. 


PORT6//FSYNC. General Purpose I/O or Frame 
Sync (input or output). Software can program the 
lUSC so that this pin is a general purpose input or 
output, or a Frame Sync input for the IUSC's Time 
Slot Assigner circuits. The IUSC captures transitions 
on this pin in internal latches, as described in the text. 


PORTS//RxSYNC. General Purpose |/O or Receive 
Sync (input or output). Software can program the 
IUSC so that this pin is a general purpose input or 
output, or so that it carries a Receive Sync output 
from the Receiver. The IUSC captures transitions on 
this pin in internal latches, as described in the text. 


PORT4//TxTSA. General Purpose I/O or Transmit 
Time Slot Assigner Gate (input or output). Software 
can program the IUSC so that this pin is a general 
purpose input or output, or so that it carries the Gate 
output of the Transmit Time Slot Assigner, that can 
enable an external TxD driver in time-slotted ISDN or 
Fractional T1 applications. The IUSC captures tran- 
sitions on this pin in internal latches, as described in 
the text. 


PORT3//RxTSA. General Purpose I/O or Receive 
Time Slot Assigner Gate (input or output). Software 
can program the IUSC so that this pin is a general 
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purpose input or output, or so that it carries the Gate 
output of the Receive Time Slot Assigner. The IUSC 
captures transitions on this pin in internal latches, as 
described in the text. 


PORT2. General Purpose I/O (input or output). 
Software can program the IUSC so that this pin is a 
general purpose input or output. The IUSC captures 
transitions on this pin in internal latches, as described 
in the text. 


PORT1-0/CLK1-0. General Purpose 1//Os_ or 
Reference Clocks (inputs or outputs). Software can 
program the IUSC so that either of these pins is a 
general purpose input or output, or a clock for the Re- 
ceiver and/or Transmitter. On the 16C32, this clock 
can be used directly as a bit clock or divided down as 
a time base. When one of these pins is a general- 
purpose I/O, the IUSC captures transitions on it in 
internal latches, as described in the text. 


Vcc, Vss. Power and Ground. The inclusion of 
seven pins for each power rail insures good signal 
integrity, prevents transients on outputs, and improves 
noise margins on inputs. The IUSC's internal power 
distribution network requires that all these pins be 
connected appropriately. 


DEVICE STRUCTURE 


Figure 1 shows the basic structure of the IUSC. The 
Bus Interface module stands between the external 
bus pins and an on-chip 16-bit data bus that intercon- 
nects the other functional modules. It includes several 
flexible interfacing options that are controlled by the 
Bus Configuration Register (BCR). The BCR is auto- 
matically the destination of the first write cycle from 
the host processor to the IUSC after a Reset; after 
that it is no longer accessible to the host software. 


The host processor or the on-chip Transmit DMA 
channel can write transmit data into a channel's 
Transmit First-In, First-Out (FIFO) memory. At any 
time, a Transmit FIFO can be empty or can contain 
from 1 to 32 characters to be transmitted. Characters 
written into the FIFO automatically migrate to its other 
end, where they become available to the Transmitter. 


While the host processor can itself write data into the 
Transmit FIFOs, it's more efficient to use the Transmit 
DMA channel to fetch the data. Software can set up 
the Transmit DMA channel to operate in any of four 
major modes. In single-buffer mode, the channel 
transfers one block of consecutive bytes from host 
memory given a programmable location and length, 
delivering the data to the Transmit FIFO, and then 
notifies the host processor and stops. Software has 
to reprogram the channel before it can transfer an- 
other block, but in many applications there is time to 
do this because the Transmit FIFO is 32 bytes deep. 
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Figure 1. 


In pipelined mode, there are two sets of buffer ad- 
dress and length registers: software can program one 
set while the DMA channel is using the other set. 
When the channel finishes transferring one block, it 
notifies the host processor. If the host has set up the 
other register set, the channel automatically proceeds 
to start transferring data from the next buffer. 


In Array mode, the host processor programs the 
Transmit DMA channel with the address of a table 
containing the addresses and lengths of the actual 
memory buffers. With the 16C32, this table can also 
contain control information for each frame. When the 
channel finishes transferring the data from one 
memory buffer to the Transmit FIFO, it automatically 
fetches the next buffer address and length from the 
table and begins to transfer the data from that buffer. 


Finally, in Linked List mode the host programs the 
channel with the address of the start of a linked list of 
buffer addresses and lengths, in which each entry 
also includes the address of the next entry. With the 
16C32, these entries can also contain control 
information for each frame. Channel operation is 
similar to operation in array-chained mode, but 
includes the extra steps of fetching the link addresses. 


The host can program the Transmitter to trigger the 
DMA controller to fill its FIFO at varying degrees of 
FIFO "emptiness". Selecting this point involves bal- 
ancing the probability and consequences of "under- 
running" the transmitter, against the overhead for the 
DMA channel to acquire and release control of the 
host bus more often. 


The Transmitter takes characters from the Transmit 
FIFO and converts them to serial data on the TxD pin. 
While this function is conceptually simple, the IUSC 
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supports many complex serial protocols, which 


increases the complexity of the Transmitter dramati- 
cally. Depending on the serial mode selected, the 
Transmitter may do any of the following in addition to 
parallel-serial conversion: start, stop, and/or parity bit 
generation, calculating and sending CRCs, automatic 
generation of opening and closing Sync or Flag 
characters, encoding the serial data into any of 
several formats that guarantee transitions and carry 
clocking with the data, and/or controlling transmission 
based on the CTS pin. The 16C32 can also send a . 
programmable minimum number of Flags between 
HDLC/SDLC frames. 


Finally, for ISDN and Fractional T1 applications the 
Transmitter section includes Time Slot Assigner logic 
that can be used to enable the Transmitter only 
periodically and for specific bytes within a multiple- 
sourced, cyclically time-multiplexed data stream. 


In general, the functions of the Receiver section are 
the inverse of those of the Transmitter: it monitors the 
serial data on the RxD pin, recognizes its organization 
according to the serial mode selected by the software, 
and convert the data to parallel characters that it 
places in the Receive FIFO. Again, there is more to 
the process than just serial-parallel conversion. 
Depending on the serial mode the Receiver may have 
to detect and synchronize start bits, check parity and 
stop bits, calculate and check CRCs, detect 
sync/Flag, Abort and/or Idle sequences, recognize 
control characters including transparency consid- 
erations, decode the serial data and extract clocking 
using any of several encoding schemes, and/or 
enable and disable reception based on the DCD input 
pin. The Receivers checking functions generate 
several status bits associated with each character, 


that accompany the characters through the Receive 
FIFO. The 16C32 can notify software of received 
HDLC/SDLC Abort sequences in real time and/or in 
the received data stream. 


The Receiver section also includes a Time Slot 
Assigner that can be used to enable reception only for 
specific bytes within a multiple-destination, cyclically 
time-multiplexed data stream like an ISDN or Frac- 
tional T1 link. 


The Receive FIFO can hold up to 32 characters and 
their associated status bits. As the receiver writes 
entries into their FIFOs, they automatically "migrate to 
the output side" where they become available to either 
the host processor or the Receive DMA channel. 
Similarly to the transmit side, the Receive FIFO 
includes detection logic for various degrees of 
"fullness". Separate thresholds control when the 
Receive DMA channel starts refilling the FIFO, and at 
which the IUSC requests an interrupt. 


While the host processor can access data from the 
Receive FIFOs, it's more efficient to use the Receive 
DMA channel to transfer the data directly into buffer 
areas in memory. As on the transmit side, software 
can program the Receive DMA channel to operate in 
Single-Buffer mode, Pipelined mode, Array mode, or 
‘Linked List mode. The 16C32 can store the status 
and length of each frame after the last character of 
each frame, or, in Array and Linked List modes, in the 
DMA control structure. 


The Serial Clocking Logic section creates the clocking 
signals for the channel's Transmitter and Receiver. 
Software can program the clocking logic to do this in 
various ways based on one or more external clock(s) 
for each channel. An on-chip Digital Phase Locked 
Loop (DPLL) circuit can recover clocking from 
encoded data on RxD. 


The Interrupt Control section gathers the various 
"request" lines from the Transmitter, Receiver, and 
the DMA channels, and takes care of requesting host 
interrupts and responding to host interrupt-acknow- 
ledge cycles or to software equivalents. Interrupt 
operation depends on the data written to the Bus 
Configuration Register and on several registers in the 
Receiver, Transmitter, and DMA channels. 


The I/O port section provides 8 pins that can be used 
for modem control lines or any other purpose. Each 
pin can be individually controlled as an input or output, 
and most of them can optionally be used for a 
specific/dedicated input or output signal. 
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DOCUMENT STRUCTURE 


This Chapters in this manual provide the first-time 
reader with a staged and gradual introduction to the 
IUSC. Chapter 2 discusses interfacing the part to 
typical processor or backplane buses. Chapter 3 dis- 
cusses how to interface the IUSC "on the serial side", 
including the various flexibilities and options available 
in doing so. Chapter 4 talks about the many serial 
protocol capabilities of the part; many readers won't 
be familiar with all the protocols described, but each 
reader should know the basics of those needed by his 
or her application. Chapter 5 describes the IUSC's 
integrated Direct Memory Access (DMA): and how to 
program them and how they operate on the system 
bus. Chapter 6 deals with interrupts. Finally, Chapter 
7 pulls together certain aspects of writing software for 
the IUSC and serves as a central programming 
reference. 


This manual is structured according to the IUSC's 
major internal blocks and various aspects of their 
operation, rather than as a list and description of each 
of its registers. The various registers and fields are 
covered in conjunction with the facilities that they 
report on and control. Chapter 7 then reviews the 
general programming model and includes a concise 
description of each register bit and field for quick 
reference. 


The actual timing parameters and electrical specifi- 
cations of the IUSC are given in the companion publi- 
cation [USC Product Specification. 


We at Zilog hope that this newly structured manual 
will make the IUSC more easily understandable and 
accessible. Naturally, it's impossible to write at the 
right level for all readers; newcomers will find some 
parts hard going, while experts will undoubtedly tire of 
full explanations of matters that "everyone knows’. 
Our target audience is neither newcomers nor 
experts, but midway between: working engineers with 
some datacom background. 


About Test Modes 


Each !IUSC channel includes a Test Mode Control 
Register (TMCR) and a Test Mode Data Register 
(TMDR) that Zilog uses to help test the device and 
ensure that customers receive only fully functional 
units. In some cases these registers might be useful 
to help hardware and software developers solve a 
knotty problem. On the other hand, this manual is big 
enough without including subjects of use to only a 
fraction of its readers. If you are interested in using 
the test modes, contact a Zilog sales office for the 
forthcoming volume USC Family Test Modes. 


2. Bus Interfacing 


The IUSC can be used in systems with various 
microprocessor or backplane buses. Its flexibility with 
respect to host bus interfacing derives from its Bus 
Configuration Register (BCR), from on-chip logic that 
monitors bus activity before software writes the BCR, 
and from certain other registers in the serial and DMA 
controllers. This section describes how to use these 
facilities to interface the IUSC to a variety of host 
microprocessors and buses. 


Multiplexed / Non-Multiplexed Operation 


One important distinction among buses is whether 
they include separate sets of lines for addresses and 
for data, or whether the same set of lines carries both 
addresses and data. As a DMA bus master the 
IUSC always operates in the latter (multiplexed) 
fashion. If the host bus doesn't multiplex addresses 
and data, they can be easily demultiplexed as 
described later. If it does (as with a Zilog 16C01), the 
AD pins of the IUSC can be directly connected to 
those of the host. 


As a DMA master the IUSC maintains 32 bit 
addresses. It presents the MS and LS 16 bits of an 
address as it drives /UAS and /AS low, respectively, 
and this information is valid at the following rising 
edge. As a slave on a multiplexed bus, the [USC 
captures addressing at rising edges on /AS. If this 
signalling is the same as that used on the host bus 
(as with a Zilog 16C01), then the IUSC's /AS pin can 
be directly connected to the corresponding bus signal. 
Figure 2 shows such a system. 


If the host's address strobe signalling is different from 
that of the IUSC (as with an 8086), then external logic 
must generate a compatible /AS signal for the |IUSC. 
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Figure 2. Simple Multiplexed System 
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Figure 3. Multiplexed System with ALE-/AS-ALE 
Remapping 


Unless the rest of the system can use this /AS signal, 
external logic must also transform the /AS and /UAS 
issued by the IUSC as a bus master, to signalling 
that's compatible with the host bus. Figure 3 shows 
such an application. 


If the host bus doesn't multiplex addresses and data, 
external devices must be added to latch the address 
when the IUSC is the bus master. Figures 4 and 5 
illustrate two ways to interface the IUSC to a non- 
multiplexed host bus. Figure 4 includes minimum | 
hardware but requires that software write the register 
address into the IUSC each time it is going to access 
a register. In this mode the IUSC's /AS pin should be 
pulled up to ensure a constant high logic level. The 
augmented interface of Figure 5 includes drivers to 
sequence the low-order bits of the host address onto 
the IUSC's AD lines, and logic to synthesize a pulse 
on the /AS pin. This interfacing method has the 
advantage that software can directly address the 
I|USC's registers. 


The IUSC monitors the /AS pin from the time the 
/RESET pin goes high until the software writes the 
Bus Configuration Register. If it sees /AS go low at 
any point in this period, then after the software writes 
the BCR, the IUSC captures the state of the low-order 
AD lines, S//D, C//D, and /CS, at each rising edge of 
/AS. lf /AS remains high, software may have to write 
each register address into the Channel or DMA 
Command/ Address Register (CCAR or DCAR) before 
reading or writing a register. (If the host bus only 
includes 8 data lines, AD13-8 can carry register 
addresses.) 


/BUSREQ  /BIN 


Figure 4. Simple Bus Demultiplexing 





A31:16 
Ctrl — 2s 







Control 
=a 


Figure 5. User-Friendly Bus Demultiplexing 


Read/Write Data Strobes 


Another difference among host buses is the way in 
which read and write cycles are signalled and differen- 
tiated. Figures 6 and 7 show two standard methods 
supported by the IUSC. In Figure 6, the bus includes 
separate strobe lines for read and write cycles, 
commonly called /RD and /WR. In Figure 7, the bus 
includes a data strobe line, /DS, that goes low for both 
read and write cycles, and a R//W line that 
differentiates read cycles from writes. The IUSC 
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includes pins for all four of these signals. The two 
that match up with host bus signals should be 
connected to those signals. The two unused pins 
should be pulled up to a high level with resistors of 
about 10K ohms. 


Read Operation: 
RD* \ / 
WR* 
Data Bus 


Write Operation: 
; RD* 


WR* \ / 
Data Bus (Sieve) ————{__F= 


Figure 6. /RD and /WR Signalling 


Read Operation: 


R//W (Master) ] \ 
R//W (Slave) ] \ 
DS* \ / 


Data Bus 


Write Operation: 


R//W (Master) \ | / 
RW (Slave) \_ 
Data Bus (Master) 
Data Bus ve 


Figure 7. R//W and /DS Signalling 





There is no programmable option for the distinction 
between /RD-/WR and R//W-/DS operation. As a 
master the IUSC simply drives all four lines as shown 
in Figures 6 and 7. As a slave the IUSC responds to 
either pair of lines, which is why it's important to pull 
up the unused pair. Also, as a slave the [USC doesn't 
demand that the R//W line remain valid throughout the 
assertion of /DS. It captures the state of R//W at the 
leading/falling edge of /DS, so that R//W need only 
satisfy setup and hold times with respect to this edge. 


Only one among the bus signals /DS, /RD, and 
/WR may be active at a time. This restriction also 
includes /INTACK if it carries a strobe rather than a 
sampled level (see Chapter 6 for more information 


about interrupts). If the IUSC detects more than one 
of these inputs active simultaneously, it enters an 
inactive state from which the only escape is via the 
/RESET pin. 


Bus Width 


Another major difference among host buses is the 
number of data bits that can be transferred in one 
cycle. Software can configure the IUSC to transfer 16 
bits at a time, in which case it is still possible to trans- 
fer 8 bits when this is necessary or desirable. Ona 
16-bit data bus, the DMA channels can transfer either 
two data characters per cycle, or one per cycle with 
alternating cycles using AD15-8 and AD7-0. 


Or, software can restrict both master and slave 
operations to transferring only 8 bits at a time, on the 
AD7-0 pins. This leaves the AD15-8 pins unused 
during slave cycles: another BCR option allows them 
to carry register addresses. The latter option allows 
software to directly address IUSC registers even on a 
non-multiplexed bus, without having to write an 
address into the IUSC before it accesses a register. 


ACK vs. WAIT Handshaking 


The final major difference among host buses involves 
the handshaking signals that slave devices use for 
speed-matching with masters. Figure 8 illustrates the 
three variations in common use. In the first, which 
we'll call Wait signalling, if a master selects a slave 
and the slave cannot capture write data or provide 
read data within the time required to keep the master 
operating at full speed, it quickly (combinatorially) 
drives a Wait output low, and then returns it to high 
when it's ready to complete the cycle. Slave Wait 
outputs that are open-collector or open-drain can be 
tied together for a negative logic wired-Or function, 
and/or a logic gate can be used to negative-logic OR 
(positive-logic AND) separate Wait lines to produce 
the /WAIT input to the master (e.g., to the processor). 


In the second scheme, "Acknowledge" signalling, all 
slaves must respond when the master directs a cycle 
to them, by driving an Acknowledge signal (some- 


RD* or WR* 
or DS* 


times called /DTACK) low to allow the master to 
complete the transfer, and keeps it low until the mas- 
ter does so. As with the previous scheme, slave Ack 
outputs that are open-collector or open-drain can be 
tied together for a negative logic wired-Or function, 
and/or a logic gate can be used to negative-logic OR 
separate Ack lines to produce the Acknowledge input 
to the master. 


In the third scheme, "Ready" signalling, all slaves 
must respond when the master directs a cycle to 
them, by driving a Ready signal high to allow the 
master to complete the transfer, and keeping it high 
until the master does so. This scheme differs from 
Wait signalling in the default state of the handshaking 
signal between cycles (high for Wait signalling, low for 
Ready). It has similar timing as Ack signalling, but 
differs in the polarity of the handshaking signal. With 
Ready signalling, the board designer must include a 
logic gate to positive-logic OR the various slaves' 
Ready lines to produce a composite Ready input for 
the bus master(s). 


The IUSC supports Acknowledge and Ready signal- 
ling for all cycles, and Wait signalling for interrupt 
acknowledge cycles. The IUSC register access times 
should be short enough to avoid the need for Wait 
signalling on all but the fastest processors. The board 
designer can combine the |USC's /WAIT//RDY output 
with similar signals from other slaves, by means of an 
external logic gate or (for Acknowledge and Wait) by 
using an external 3-state or open-collector driver. 


The next section describes how software can select 
which way the IUSC drives its /WAIT//RDY pin, 
depending on the address at which it writes the Bus 
Configuration Register (BCR). 


Ready signalling can be handled by using 
Acknowledge signalling and inverting the sense of the 
signal. When doing this, remember that /WAIT//RDY 
is bidirectional if the on-chip DMA channels are used. 


a es SD 


WAIT* \ / 


ACK* \ / \ / 
Ready / \ / \ 





Figure 8. A Fast and Slow Cycle, with Three Kinds of Handshaking 
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15 14 13 12 11 10 9 8 


5 4 3 2 1 0 


7 6 


Figure 8. The 16C32's Bus Configuration Register (BCR) 


The Bus Configuration Register (BCR) 


The BCR is a 16-bit register having the format shown 
in Figure 9. All the bits in the BCR reset to zero. lf 
the host processor handles 16-bit data, and the data 
bus between it and the IUSC is at least 16 bits wide, 
then the software's initial access to the IUSC should 
be a 16-bit write. This write can be to any address 
that activates the /CS pin; the data will be placed in 
the BCR. If the host can only write bytes to the IUSC, 
all data should be transferred on the AD7-0 pins. In 
such a system, pull-down resistors of about 10KOhms 
should be attached to the AD15-8 pins to ensure the 
state of these lines during the BCR write. (AD15 may 
want to be pulled up instead of down, as described in 
the section on the SepAd bit below.) 


The following paragraphs describe the significance of 
the various bits and fields in the BCR. Besides these 
data bits, the IUSC captures the state of the S//D pin 
when the software writes the BCR. It uses this 
captured state after the BCR write, such that if S//D 
was low, it drives the /WAIT//RDY pin as an "acknow- 
ledge" (or an inverted "ready") signal during register 
accesses and interrupt acknowledge cycles, while if 
S//D was high, it drives the pin as a "wait" signal 
during interrupt acknowledge cycles only. Therefore, 
software should program the BCR at an address that 
corresponds to the kind of slave-to-master hand- 
shaking used on the host bus. 


SepAd (Separate Address; BCR15): this bit should 
only be written as 1 with 16Bit=0. This combination 
conditions the |USC to use AD7-0 for data and to take 
register addressing from AD13-8. In this mode the 
IUSC takes the Upper/Lower byte indication (U//L) 
from AD8 and the register address from AD13-9. The 
external drivers for these signals must be 3-stated 
when the IUSC is the bus master. 


With this interfacing technique, the BCR must be 
written at an address such that AD13-8 are low/zero. 
Further, AD15 must be high/one and AD14 must be 
low/zero when software writes the BCR. The designer 
can ensure this by connecting AD15 and AD14 to 
more-significant address lines and writing the BCR at 
an appropriate address. Alternatively, the designer 
can ensure this by connecting a pull-up resistor to 
AD15 and a pulldown resistor to AD14, both being 
about 10K ohms. 


This mode is useful with a non-multiplexed bus, to 
avoid making the software write a register address to 
CCAR or DCAR before each register access. In this 
mode the IUSC captures the state of AD13-8 on each 
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leading/ falling edge on /DS, /RD, or /WR. But 
software can still program SepAd=1 (with 16Bit=0) 
when the IUSC has detected early activity on /AS. In 
this case the IUSC captures addressing from AD13-8 
on each rising edge of /AS, rather than from the low- 
order AD lines as would be true with SepAd=0. 


The predecessor 16C31 device used BCR7-6 as a 
"ByteSwap" field that controlled how the Transmit 
DMA channel captured bytes from the D15-0 lines 
when it was reading bytes over a 16-bit bus. On the 
16C32 these bits are Reserved -- software written for 
the 16C31 may program them with 10 or 11, but new 
software should write 00 to this field. (In effect, the 
16C32's Transmit DMA channel uses 16Bit (BCR2) in 
place of BCR7, to control whether it fetches bytes 
from the two halves of the bus alternately, and uses 
the state bit that's controlled by "Select D15-8 or D7-0 
First" commands in place of BCR6, to control which 
half of the bus corresponds to even and odd 
addresses. f 


The lAckMode field (BCR5-4) controls how the host 
processor drives the /INTACK pin. 00 indicates that 
the IUSC should capture the state of /INTACK at the 
start of each bus cycle. On a multiplexed bus it does 
this at rising edges on /AS, while on a bus with 
separate address and data lines it does so at falling 
edges on /DS or /RD. 


This field should be 01 if /INTACK carries a single 
low-active pulse during interrupt acknowledge cycles. 


The 10 value in this field is reserved and should not 
be programmed. 


|[AckMode should be 11 if /INTACK carries two pulses 
during an interrupt acknowledge sequence. This 
mode is compatible with several intel microproc- 
essors. 


BRQTP (Bus Request Totem-Pole; BCR3): if this bit is 
1, the IUSC drives its /BUSREQ pin in a toism-pole 
fashion (both high and low). If it is 0, the IUSC crives 
/BUSREQ in an open-drain fashion (low only), in 
which case an external pull-up resistor should be 
provided. In the latter case, the IUSC samples 
/BUSREQ before driving it; if the pin is low, the logic 
waits until it goes high before driving it back to low. 


16Bit (BCR2): this bit should be written as 1 when the 
host data bus is 16 bits wide (or wider). Writing this 
bit as O has three effects: it restricts the IUSC to using 
byte operations on AD7-0 when it is the bus master, !t 
restricts the host to using byte transfers on AD7-0 
when reading and writing the IUSC's registers, and it 


makes the IUSC ignore the state of the "B//W" signal 
or bit for register accesses. This bit also controls 
whether "implicit" accesses to the CCAR, TDR, RDR, 
and DCAR are 8 or 16 bit wide. 


/IRQTP (Interrupt Request Totem-Pole; BCR1): if this 
bit is 0, the IUSC drives its /INT pin in a totem-pole 
fashion (both high and low). If /IRQTP is 1, the lIUSC 
drives /INT in an open-drain fashion (low only), in 
which case it should have an external pull-up resistor. 


SRightA (Shift Right Addresses; BCRO): this bit is 
significant only for a multiplexed bus -- the IUSC 
ignores it for a non-multiplexed bus. If SRightA is 1, 
the IUSC captures slave register addressing from the 
AD6-0 pins and ignores the AD7 pin. In this mode, 
ADO carries the Upper/Lower byte indication (U//L), 
AD5-1 carry the actual register address, and AD6 
carries the Byte/Word indication (B//W). If SRightA is 
0, the IUSC captures addressing from AD7-1 and 
ignores ADO. It takes U//L from AD1, the register 
address from AD6-2, and B//W from AD7. This bit 
applies to accesses to both the serial and DMA 
sections of the |USC, but it has no effect on the use of 
the S//D and D//C pins. 


SRightA would be 0 in order to use the IUSC as an 
8-bit peripheral on a 16-bit bus, which isn't likely 
to be a common application. Some sections of 
this manual assume that SRightA is 1. 


All other bits in the BCR are reserved and should be 
programmed as 0. If the processor can only write 
bytes to the I|USC, software should start by writing the 
8 LSBits of the BCR on the AD7-0 lines. In this case, 
the state of AD15-8, when software writes the BCR, 
must be ensured by connecting these pins to pulldown 
resistors of about 10Kohms or, if SepAd=1, to host 
address lines. 


Register Addressing 


Tables 1 and 2 show the names and addresses of the 

addressable registers in the IUSC, in address and 

alphabetical order. As already noted, the device can 
take register addresses from any of several sources: 

(1) from the AD6-0 lines as latched at the rising edge 
of /AS, assuming SRightA (BCRO) is 1, 

(2) from the AD13-8 lines as latched at the rising 
edge of /AS, /DS, /RD, or /WR, 

(3) for serial controller registers, from the least 
significant 7 bits of the Channel Command/ 
Address Register (CCAR), namely the B//W. 
RegAddr, and U//L bits/fields. (Figure 10 shows 
the CCAR.), and/or 

(4) for DMA controller registers, from the LS 8 bits of 
the DMA Command/Address Register (DCAR), 
namely the Rx/Tx Reg, B//W, RegAddr, and U//L 
bits/fields. (Figure 11 shows the DCAR.) 


The Tables assume that SRightA (BCRO) is 1. The 
RegAddr column in the Tables reflects the state of 
AD5-1, AD13-9, CCAR5-1, or DCARS5-1 as applicable. 


lf 16Bit (BCR2) is 1, the state of AD6, AD14, CCAR6, 
or DCAR6 selects between a 16-bit transfer (if O/low) 
and an 8-bit transfer (if 1). If "16Bit" is 0, the IUSC 
ignores AD6, AD14, CCAR6, or DCAR6 (as applic- 
able). Note that the values in the "8-bit data" columns 
of Tables 1 and 2 include the B//W bit 1 for both direct 
and indirect addressing, as is required on a 16-bit 
bus. When 16Bit (BCR2) is 0 these address values 
can be used as shown, or 64 lower like the addresses 
shown in the "16-bit data" columns. 


For 8-bit transfers on either an 8- or 16-bit bus, the 
state of ADO, AD8, CCARO, or DCARO selects the 
less-significant 8 bits of the register (if O/low) or the 
more-significant 8 bits if 1/high. In this regard, and in 
the register addresses of the two halves of the 32-bit 
DMA address registers, the IUSC is “little Endian" like 
Intel microprocessors. (The next section describes 
the IUSC's byte-ordering flexibility for DMA oper- 
ations.) For 16-bit transfers, ADO, AD8, or CCARO 
must be O/low. 


RT Chan 
RTCmd RTMode B//W RegAddr U//L 


15 14 13 12 11 10 9 8 


rg 6 5 4 3 2 } 0) 


Figure 10. The Channel Command/Address Register (CCAR) 


15 14 13 12 


11 10 9 8 7 6 


5 4 3 2 1 0 


Figure 11. The DMA Command /Address Register (DCAR) 


The Direct Address columns of the Tables assume: 

(1) SRightA (BCRO) is 1, 

(2) the processor's multiplexed AD6-0 lines are 
connected to AD6-0, or its A5-0 lines are 
connected to AD13-8, depending on SepAd 
(BCR15), 

(3) the processor's A7 line is connected to D//C, and 

(4) the processor's A8 line is connected to S//D. 


lf your design differs from these assumptions, register 
addressing will be different from that shown in the 
Direct Address columns. 


The IUSC provides certain “implicit addressing" 
features that are intended mainly to make indirect 
addressing more convenient for host software. Three 
notes indicated in the Tables relate to these features: 


(Note 1):If S//D is low and no other source of 
addressing applies, that is, if the IUSC 
considers the bus non-multiplexed because it 
did not see activity on the /AS pin after 
Reset, the SepAd bit (BCR15) is 0, and 
DCARS5-0 are all zero, the IUSC assumes a 
reference to DCAR. If 16Bit (BCR2) is 1, it 
assumes a 16-bit access, while if 16Bit=0 it 
assumes an access to DCAR7-0. 


lf S//D is high and no other source of 
addressing applies, that is, if the IUSC 
considers the bus non-multiplexed because it 
did not see activity on the /AS pin after 
Reset, the SepAd bit (BCR15) is 0, D//C is 
low, and CCARS5-0O are all zero, then the 
IUSC assumes a reference to CCAR. If 
16Bit (BCR2) is 1, it assumes a 16-bit 
access, while 16Bit=0 it assumes an access 
to CCAR7-0. 


(Note 3):If S//D and D//C are both high for a write 
operation, the IUSC assumes a write to the 
Transmit Data Register (TDR), while if S//D 
and D//C are both high for a read, it provides 
data from the Receive Data Register (RDR). 
For both Reads and Writes, if 16Bit (BCR2) 


(Note 2): 
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is 1 the IUSC assumes a 16 bit access, while 
if 16Bit=0 it assumes an access to the less- 
significant byte. 


(On a 16-bit bus, this means that software 
can neither write a byte to the TDR/TxFIFO 
nor read a byte from the RDR/RxFIFO using 
an address that makes D//C high. Instead, 
software must provide the explicit address of 
the LSbyte of the TDR/RDR, either directly or 
by writing it to the CCAR. 


The RDR and TDR have certain other special 
characteristics: 


1. They are actually "the read and write sides of" the 
same register location. The IUSC ignores the 
state of AD4, AD12, or CCAR4 (as applicable) 
whenever the rest of the address indicates an 
access to TDR or RDR. For simplicity Tables 1 
and 2 show RDR at the lower address and TDR at 
the higher one. 


The MSBytes of RDR and TDR should never be 
read or written alone, only as part of a 16-bit 
access. On a Zilog 16COx or Motorola 680x0 
system, use direct addresses 353 or 369 (161 or 
171 hex) to select the LSByte for byte transfers. 
On an Intel-based system, use direct addresses 
352 or 368 (160 or 170 hex) to select the LSByte 
for byte transfers. 


The direct, indirect, and implicit addressing features of 
the IUSC interact in several ways. For example, 
CCAR or DCAR can always be used to select a 
register for a subsequent access to the CCAR or 
DCAR address. This is true whether or not the |USC 
detected activity on /AS after Reset, and regardless of 
the state of SepAd (BCR15). 


The flowchart of Figures 12 and 13 shows the 
complete process by which the IUSC determines 
which register to access when a host processor cycle 
asserts /CS and one of /RD, /WR, or /DS. 


Register Name Acronym 


Reg Direct Direct DCAR7-0 or 

$//D D//C Addr Address: | Addresses: | CCAR6-0: 

16-bit data} 8-bitdata | 16-bit data 

[= feo | ove [wera | gay 

| x =| coor | 6/6 =| 701/467 | 6/6 | 

| x [ooo] s/s | 723/489 | 8/8 | 

| x | 01001 |_ 18/12 | 823/523 | 18/12 | 

| x =| 01010 | 20/14 | 845/545 | 20/14 | 
ae 


DMA Command / Address 


Transmit DMA Mode 
DMA Control 

DMA Array Count 
Burst / Dwell Control 
DMA Interrupt Vector 
DMA Interrupt Control 
Clear DMA Interrupt 

Set DMA Interrupt 

Transmit OMA Interrupt Arm 


Ss 


TOMR 
R 
DACR 
BDCR 
DIVR 
DICR 
CD! 


em | es oe | cee | see | oe | 
O 1[O [O 10 [O [|O 


| 01101 | 26/1A 
106,7 / 6A,B 


TDIA 


a) 






a oO 
% Sig] 2 
Cc D DD 
a | om 
O10 [0 [oO 


Transmit Byte Count TBCR | L 
Transmit Address (Lower TARL | L(0) | L(O) | 10110 | 44/2C | 1089/6C,D | 44/2C | 
Transmit Address (Upper 
Next Transmit Byte Count NTBCR 

Next Transmit Address (Lower) | NTARL 
Next Transmit Address (Upper)_| NTARU 

Recelve DMA Mode 
Recelve DMA Interrupt Arm RDIAR 

Receive Byte Count RBCR 
Recelve Address (Lower RARL 
Receive Address (Upper RARU 
Next Receive Byte Count NRBCR 

Next Receive Address (Lower 
Next Recelve Address (Upper 
L ; 


Channel Command / Address CCAR 00000 | 256/100 | 320,1 / 140,1 oe : 


Channel Mode 322,3 / 142,3 

Channel Command / Status 00010 

Channel Control | ccR | H(t) [| Lo) [ 00011 | 262/106 | 326,7/146,7| 6/6 | 

Port Status 00100 

| -H(1) | L (0) | 00101 | 266/10A |330,1/144B| 10/0A_| 

Test Mode Data | TMDR | H(1) [| L(0) [ 00110 | 268/10C |332,3/14C,D| 12/0C | 

Test Mode Control 
| 336,7 / 150,1 | 


uv 
ah 
D 
a 


Port Control 


DCAR7-0 or 
CCAR6-0: 
8-bit data 
64,5 / 40,1 

note 1 
66,7 / 42,3 
70,1 / 46,7 
72,3 / 48,9 
82,3 / 52,3 
84,5 / 54,5 
88,9 / 58,9 

90,1 /5A,B 
92,3 /5C,D 
94,5 /5E,F 

106,7/6A,B 

108,9 /6C,D 
110,1 / 6E,F 

122,3/7A,B 

124,5/7C,D 

126,7 / 7E,F 
194,5/C2,3 

222,3 / DE,F 

234,5 /EA,B 

236,7 /EC,D 

238,9 / EE,F 

250,1 / FA,B 

252,3 /FC,D 

254,5 / FE,F 
64,65 / 40,1 

note 2 
66,7 / 42,3 
68,9 / 44,5 
70,1 / 46,7 
72,3 / 48,9 
74,5/4A,B 
76,7 /4C,D 
78,9 /4E,F 


0 

Clock Mode Control 336,7 / 150,1 80,1 / 50,1 

Hardware Configuration 82,3 / 52,3 

Interrupt Vector 84,5 / 54,5 

Input / Output Control 86,7 / 56,7 
Interrupt Control 
Daisy-Chain Control 
Miscellaneous Interrupt Status | MISR | H(1) | L@) | 01110 | 284/11C [348,9/15C,D} 28/1C | 92,3/5C,D | 

(Read only; TOR for Write) orH(1) 00m 384-511 384-511 NOOK OOK 

| SS CRecelve Mode | SC RMR_ | C(I) | LO) | 10001 | 290/122 | 3545/1623 | 34/22 | 98,9/62,3 | 
| __ Receive Command/Status_ | RCSR_ | H(1) | L(o) | 10010 | 202/124 | 356,7/164.5| 36/24 | 100,1/64,5 | 
| Receive Sync | SC RSR | C(I) | LO) | 10100 | 296/128 | 360,1/168,9 | 40/28 | 104,5/68,9 | 

Transmit Data TDR H(1) L (0) 1x000 304/130 (note 3) 48 /30 112/70 

(Write only; ROR for Read) or H(1)  10xx 384-511 384-511 200 00K 

| TransmitCommand/Status_ | TCSR | H(1) | (0) | 11010 | 308/134 | 3723/1745 | 52/34 | 116,7/74,5 | 
11011 
376,7 /178,9 
| Transmit Count Limit =| = TCLR {| H(1) | L(0) | 11101 | 314/13A |378,9/17AB| 58/3A_ | 122,3/7A,B | 
|___ Transmit CharacterCount_ {| TCCR | H(1) | L(O) | 11110 | 316/13C |380,1/17C,D| 60/3C_| 124,5/7C,D | 
| TimeConstant1 =| TCIR, | H(1) [| LO) | 11111 | 318/13E [382,3/17E,F | 62/3E | 126,7/7E,F 


Table 1. l1USC Registers, in address order 


Register Name 


Burst / Dwell Control 
Channel Command / Address 


Channel Command / Status 
Channel Control 
Channel Mode 
Clear DMA Interrupt 
Clock Mode Control 
Daisy-Chain Control 
DMA Array Count 


DMA Command / Address 


DMA Control 
DMA Interrupt Control 
DMA Interrupt Vector 
Hardware Configuration 
Input / Output Control 
Interrupt Control 
Interrupt Vector 
Miscellaneous Interrupt Status 
Next Receive Address (Lower 
Next Receive Address (Upper 
Next Receive Byte Count 
Next Transmit Address (Lower 
Next Transmit Address (Upper) 
Next Transmit Byte Count 
Port Control 
Port Status 
Receive Address (Lower 
Receive Address (Upper 
Receive Byte Count 
Receive Character Count 
Receive Command / Status 
Receive Count Limit 
Receive Data 
(Read only; TDR for Write) 
Receive DMA Interrupt Arm 
Receive DMA Mode 
Receive Interrupt Control 
Receive Mode 
Receive Sync 
Set DMA Interrupt 
Status Interrupt Control 
Test Mode Control 
Test Mode Data 
Time Constant 0 
Time Constant 1 
Transmit Address (Lower 
Transmit Address (Upper 
Transmit Byte Count . 
Transmit Character Count 
Transmit Command / Status 
Transmit Count Limit 
Transmit Data 
(Write only; RDR for Read) 
Transmit DMA Interrupt Arm 
Transmit DMA Mode 
Transmit Interrupt Control 
Transmit Mode 
Transmit Sync 


Direct Direct DCAR7-0 or 
Address: | Addresses: | CCAR6-0: 
16-bit data; 8-bitdata {| 16-bit data 


01001 18/12 82,3 / 52,3 18/12 


(0) | 00000 | 256/100 | 320,1 / 140,1 
note 2 


0010 | 260/104 
0 262/106 | 326,7/146,7 
0001 | 258/102 | 3223/1423 


s/D | D//C 


0] 
oO 


| 4 PY) 2 

w|> = 

Ola g OlZ15 = re) 
DIC D Disp a D 


CCAR 


CCSR 
CCR 


a2e@ 
— 
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ae 
Oo 
oOl— 
—~1O 


Trcic izry xT IT 
cr 


DCR 
DICR 
DIVR 
HCR 
1OCR 
ICR 
IVR 


CDIR 

CMCR_| H(t 272/110 

DCCR 

DACR 
note 1 


342.3 / 156,7 

344,5 / 158,9 
3 5 

D 


282/11A | 346,7/15A,B| 26/1A 


—_ fe fe fe 
O1O /O};— 
—~10 |= 10 |= 
= i= 10 JO |— 


Oo 


40,1 / 154, 


ciel] Icicic 
x| x Sla|* {lola 


NRARL 
NRARU 
NRBCR 
NTARL 
NTARU 
NTBCR 
PCR 


TIT Cyc Cyc ye 
Oi * Lt [OC [0 [0 [O [O 


RARL 
RARU 
RBCR 
RCCR 
RCSR 


OLOlOP PP LColololo 


XIII eee ec cdc ac cy |e 
{“~L[flOlloPFlolelowo woo bPeeebekeleletlLe] L& 


Cec cy yay yc aye ie ie 


1x000 304/130 (note 3) 48/30 
XXXXX 384-511 384-511 


TOR 


Table 2. IUSC Registers, in alphabetical order 


TC yr xX jzit 
= 
re) 
=r 
} 
—_ j= 


DCAR7-0 or 
CCAR6E-0: 
8-bit data 
82,3 / 52,3 
64,5 / 40,1 

note 2 
68,9 / 44,5 
70,1 / 46,7 
66,7 / 42,3 

0,1/5A,B 
80,1 / 50,1 
90,1 /5A,B 
72,3 / 48,9 
64,5 / 40,1 

note 1 
70,1 / 46,7 

8,9 / 58,9 

45/545 
82,3 / 52,3 
86,7 / 56,7 
88,9 / 58,9 
84,5 /54,5 
92,3/5C,D 

252,3 /FC,D 
254,5 / FE,F 
250,1/FA,B 
124,5/7C,D 
126,7 / 7E,F 
122,3/7A,B 
74,5 /4A,B 
72,3 / 48,9 

236,7/EC,D 

208,97 EEF 
234,5/EA,B 
108,9/6C,D 
100,1 / 64,5 


co 


RCLR | L(0) | 10101 | 208/12A |362,3/16A,B| 42/2A | 106,7/6A,B 
or H(1 XXXXX 384-511 384-511 XXX XXX 

RD 

01110 
SICR 
TMCR 
TMDR 
TCIR 
TARL 
TCCR 
TCSR 1 
TCLR 1 314/13A 


112/70 


TDIAR 0 30/1E 
0 
1 
11100 376,7 / 178,9 


Start: Host Cycle 
with /CS low -- 
which register to R/W?? 























Capture S//D,, 
iD/C:=D//C at fall 
of /DS, /RD, or WR 


Activity 
on /AS after 
Reset? 





Ad) 


(Separate Yes | (Mux'ed Bus) 
Addr) 
















Capture S//D, B/W:= 
AD6, RegAd:=AD5-0, 
iD/C := D//C 
at rise of /AS 











High/1 
(Serial) 


Capture S//D, 
RegAd := AD13-8, 
iD/C := D//C 
at rise of /AS 








Activity 
on /AS after 
Reset? 











(Non-Mux'ed 
Bus) 


Capture S//D, 
RegAd := AD13-8, 


Low/0 | (DMA) 





RegAd := DCARS-0; 
Yes B/W = DCAR6; 


ID/C := D/C at fal Regneees D/C:=iD/C or DCART: 
of /DS, /RD, or WR then DCAR5-0 := 0 
No 
RegAd := CCARS-0; 
16BIT 1 , 
(BCR2) B/W := CCARE; 
then CCARS5-0 := 0 
0 


(Control) 


Force B//W 


‘= 1 (Byte) 





To "A" on Next Sheet 


B/W := NOT 16BIT 
(BCR2) 





To "B" on Next Sheet 
Figure 12. IUSC Register Addressing (1 of 2) 
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"A" From First Sheet 


a Sharable 
reg? 


High 
/1 


(Serial) 


High / 1 


(Control) 


DMA register 
selected by (RegAd), 


Access the DMA 
register selected 
by (RegAd), 
8/16 bits per B/W 


Access the Receive 
DMA register 
selected by (RegAd), 
8/16 bits per B/W 


“B" From First Sheet 


8/16 bits per B/W 


Read 


RegAd 
= 1x000 ? 


No Write 


Access the Serial 
Controller register 
selected by (RegAd), 
8/16 bits per B//W 


or 


Write? 


Read 1 or 2 
characters from the 
RxFIFO, depending 

on B//W 


Write 1 or 2 
characters to the 
TxFIFO, depending 
on B/W 





Figure 13. IUSC Register Addressing (2 of 2) 


Byte Ordering 


Various microprocessors differ on the correspondence 
between addresses and how bytes are arranged with- 
in a 16- or 32-bit value. The Zilog Z80 family and 
most Intel processors use what's sometimes called 
the "Little-Endian" convention: the least significant 
byte of a word has the smallest address, and the most 
significant byte has the largest address. The Zilog 
16COx and Motorola 680x0 processors are "Big- 
Endian": they store and fetch the MSByte in the 
lowest-addressed byte, and the LSByte from the 
highest address. 


The 16C32 includes two separate control facilities that 
allow it to be used with either kind of processor. The 
"Select D15-8 First" and "Select D7-0 First" 
commands in the RTCmd field of the Channel 
Command / Address Register (CCAR15-11) control 
the byte ordering within a 16-bit transfer of serial data, 
and apply to DMA and processor accesses to RDR 


and TDR. These commands also contro! which data 
lines the Transmit DMA channel takes byte data from 
on a 16-bit bus. The ALBVO bit in the DMA Control 
Register (DCR12) controls how the DMA channels 
fetcn buffer addresses and lengths from memory 
when operating in "Array" or "Linked List" mode. The 
following table summarizes how these bits should be 
ileal for various system configurations: 


a a 16Bit (BCR2) : 
ALBVO och = 1 
Little-Endian 


16Bit (BCR2) := 
ALBVO ay ‘= 0 
Big-Endian 
Little-Endian 



















16Bit (BCR2) := 1 
ALBVO (DCR12) := 1 
RTCmd (CCAR15-11) := 
16Bit (BCR2) := 1 
ALBVO (DCR12) := 
RTCmd (CCAR15- . ‘= 










"Select 015-8 First" 











"Select D7-0 First" 


Register Read and Write Cycles 


Figures 14 through 17 show the waveforms of the sig- 
nals involved when the host processor reads or writes 
an |USC register. Separate drawings are included for 
the signalling on a bus with multiplexed addresses 
and data, and for a bus with separate address and 
data lines. On the other hand, since waveforms get 
pretty boring after the first few, several things have 
been done to minimize the number of figures. 


1. The cases of separate read and write strobes, vs. 
a direction line and a data strobe, have been com- 
bined by labelling the strobe traces as "/DS or 
/RD" and "/DS or WR". The direction line R//W is 
shown in the figures, but a note reminds readers 
that its state doesn't matter with /RD and /WR. 


2. The difference between "wait" and "acknowledge" 
signalling is handled by showing the /WAIT//RDY 
trace as "maybe or maybe not" going low, with 
appropriate labelling. (The IUSC never asserts a 
"Wait" indication during a register access cycle.) 


3. The difference between a sampled (address-like) 
/INTACK signal, and one that's a strobe, is 
handled by showing it "maybe or maybe not" 
going low after the address-sampling time, again 
with appropriate labelling. 


Chapter 5 covers details of DMA cycles initiated by 
the IUSC as the bus master, while Chapter 6 covers 
interrupt acknowledge cycles. 


The actual timing parameters and electrical specifi- 
cations of the IUSC are given in the companion publi- 
cation [USC Product Specification. 


| | 
! 
s//D, D/C | ‘| 


| 
[Cs | 


/INTACK | 


aso (only if lackMode=00) 


ee eee Cais 


/WR, (/RD or /DS) | 
| 


[AS 


| 
| 


— req'd with /DS, not with /RD) 
R//W | | \ 


/DS or /RD \ | of 
| Wait mode 


/WAIT//RDY 


Acknowledge mode 





Figure 14. A Register Read Cycle with Multiplexed Addresses and Data 


ADnn 
S//D, D//C 
ICS 


/[INTACK 


/RD, (WR or /DS) 


[AS 


R//W 


/DS or /WR 


/WAIT//RDY 


| 


ith /DS, not with /WR) 


Wait mode 


Acknowledge mode 





Figure 15. A Register Write Cycle with Multiplexed Addresses and Data 


DMA Cycle Options 


Three bits in the DMA Control Register (DCR) affect 
how the IUSC operates as a bus master -- that is, 
how it acts when it has control of the bus. This 
information is presented both here and in Chapter 5. 


S//D, D//C Status Output 


The DCSDOut bit (DCR4) controls whether the IUSC 
drives the S//D and D//C pins when it is the bus 
master. If DCSDOut is 1, the IUSC drives S//D Low 
for Tx channel operations and High for Rx channel 
cycles, and drives D//C High during transfers of serial 
data and Low during array or linked-list fetching. 
When this bit is 1, the external drivers for S//D and 
D//C must be 3-stated (released) while the IUSC is 
the bus master, that is, while the /BIN pin is low. 
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If external logic has no use for the information 
described above, software can program DCSDOut as 
QO. In this case the IUSC doesn't drive S//D and D//C, 
and these pins can be driven full-time by the host 
processor or bus interface. 


Wait Insertion 


If the 1Wait bit (DCR3) is 1, the IUSC extends the 
data portion of each master bus cycle by one CLK 
period. This allows use of slower memories for a 
given CLK frequency, or use of a faster CLK 
frequency with a particular memory type. Signalling 
on /WAIT//RDY can be used to extend master bus 
cycles, regardless of the state of this bit. When 1Wait 
is 1 the IUSC starts actively sampling /WAIT//RDY 
one CLK period later than when it's 0. 


ADnn 


S//D, D//C 


[CS 


[INTACK 


/AS, /WR, (/RD or /DS) 


R//W 


/DS or /RD 


/WAIT//RDY 


| 7 coas (only if lackMode=00) 
ae 


el (req'd with /DS, not with /RD) 
Ti 


== si Wait mode 
: a mode 


Figure 16. A Register Read Cycle with Non-Multiplexed Data Lines 


/UAS Frequency 


Since the DMA channels maintain 32-bit addresses 
but have only a 16-bit external bus, they present each 
address in two parts. They signal the availability of 
the more significant half of an address by driving 
/UAS low, and signal that the LS half of an address is 
on the AD lines by driving /AS low. The UASAII bit 
(DCR2) controls how often the channels present the 
more-significant half of the address. If UASAII is 1, 
every master bus cycle includes presentation of the 
more-significant half of the address on the AD15-0 
pins, with a low-going pulse on /UAS. This means 
that every bus cycle takes at least 4 cycles of CLK. 


If UASAII is 0, the I1USC includes a /UAS sequence 

only in cycles that meet one or more of the following 

criteria: 

1. in the first cycle after taking control of the bus 
from another master, 


in the first cycle after switching from one channel 
to the other, 


a 
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3. in Pipelined mode, in the first cycle after switching 
from one buffer to the next, 

4. for a channel in Array or Linked List mode, in 
every cycle that accesses the array or list, 

5. for a channel in Array or Linked List mode, in the 
first data cycle after fetching from the array or list, 
or 

6. in the first cycle after incrementing a_ buffer 


address results in a carry from A15 to A16, even if 
the AddrSeg field (DCR1-0) is 10 so that the carry 
is blocked. 


When the IUSC includes a /UAS sequence in a bus 
cycle, the minimum length of the bus cycle is 4 CLK 
periods, while if it doesn't the bus cycle can be as 
short as 3 CLKs. 


UASAII should be programmed as 1 only if 
required by unusual external hardware. — For 
example, if the IUSC and another bus master share 
an upper-address latch and the other bus master can 
insert cycles between IUSC cycles within the same 
bus grant, UASAII would want to be 1. 


ADnn 


S//D, D//C 


[CS 
/INTACK 


/AS, /WR, (/RD or jos) 


L OP d with /DS, not with /RD) 


/DS or /RD 
a Wait mode 


/WAIT//RDY \ | 
Prem mode 


Figure 17. A Register Write Cycle with Non-Multiplexed Data Lines 
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3. Serial Interfacing 


The IUSC includes several serial interface options and 
features that promote its usefulness in many different 
kinds of applications. It allows a variety of clocking 
schemes, and will do serial encoding and decoding for 
NRZI and Biphase formats that carry clocking infor- 
mation with the serial data. The JUSC_ further 
supports such decoding with an on-chip Digital Phase 
Locked Loop circuit. It also provides specialized and 
general purpose I/O lines that can be connected to 
modem control and status signals, to other control 
and status lines related to the serial link, or even to 
input and/or output signals that aren't related to the 
serial link at all. Finally, for time-division-multiplexed 
links such as ISDN and Fractional T1 circuits, the 
I\USC includes separate Time S/ot Assigner modules 
for the Receiver and Transmitter. Each "TSA" 
restricts active operation to a programmable time 
window within a cyclic time-multiplexed data stream. 


Transmit and Receive Clocking 


The IUSC's Receiver and Transmitter logic have 
separate internal clock signals that we'll call RxCLK 
and TxCLK. In most of the IUSC's operating modes, 
the Receiver samples a new bit on RxD once per 
cycle of RxCLK, and the Transmitter presents a new 
bit on TxD for each cycle of TxCLK. One exception is 
asynchronous mode, in which RxCLK and TxCLK run 
at 16, 32, or 64 times the bit rate on RxD and TxD 
respectively. The other exception is with Biphase- 
encoded serial data, for which the Receiver samples 
RxD on both edges of RxCLK, and the Transmitter 
may change TxD on both edges of TxCLK. 


Figure 18 shows how RxCLK and TxCLK can be 
derived in several different ways. This flexibility is an 
important part of the IUSC's ability to adapt to a wide 
range of applications. 


In the simplest case, external logic derives clocks 
indicating bit boundaries, and software programs the 
lIUSC to take RxCLK directly from the /RxC pin and 
TxCLK directly from the /TxC pin. When an IUSC 
uses such external clocking for synchronous operation 
with "NRZ" data, it samples a new bit on the RxD pin 
on each rising edge on /RxC, and presents each new 
bit on the TxD pin on the falling edge of /TxC. 


It is often desirable to vary the bit rates for transmis- 
sion and reception by programming the IUSC, rather 
than by means of off-chip hardware. To provide for 
this, the IUSC includes various means by which high- 
speed clocking on one or more of the /RxC, /TxC. 
PORT1, or PORTO pins can be divided down to 
almost any desired bit rate. 
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CTRO and CTR1 


Two separate 5-bit counters called CTRO and CTR! 
comprise the first stage of the |USC's clock-gener- 
ation logic. Figure 19 shows the Clock Mode Control 
Register. Its CTROSre and CTRiSrc fields 
(CMCR13-12 and CMCR15-14 respectively) control 
whether each counter runs and whether it takes its 
input from the /RxC, /TxC, PORTO, or PORT1 pin: 


CTRnNSRC CTRn clock source 
00 CTRn disabled 
01 cCTRn input = PORTn/CLKn pin 
10 cCTRn input = /RxC pin 
11 CTRn input = /TxC pin 


Figure 20 shows the Hardware Configuration Register. 
lts CTRODiv field (HCR15-14) controls the factor by 
which CTRO divides its input to produce its output: 


CTRODiv CTRO operation 
00° -CTRO “OUEDUt = <nput 732 
O01 CTRO output = input / 16 
10: .“CTRO. cutput-=— tnput:.7 3 
11. -CTRO. output = input 7 4 
There were not enough register bits to allow a 


separate 2-bit "CTR1Div' field. If the CTR1DSel bit 
in the Hardware Configuration Register (HCR193) is 0, 
the CTRODiv field determines the factor by which both 
CTR1 and CTRO divide their inputs to produce their 
outputs. If CTR1DSel is 1, the DPLLDiv field in the 
Hardware Configuration Register (HCR11-10) deter- 
mines the factor by which both CTR1 and the DPLL 
divide their inputs to produce their outputs. In either 
case, the IUSC interprets the selected 2-bit field as 
shown above for CTRODiv. 


Using PORTO and/or PORT1 as a Bit Clock 


With the 16C32, a clock on the PORTO/CLKO and/or 
PORT1/CLK1 pin(s) can be used directly as RxCLK 
and/or TxCLK, without being divided down by CTRO/ 
CTR1 respectively. This feature is controlled by the 
CtrBypass bit in the Channel Command / Status 
Register (CCSR5), which was Reserved in the 16C31. 


When this bit is 0, the 16C32 operates like the 16C31, 
in that the outputs of CTRO and CTR1 can be used 
directly as RxCLK and/or TxCLK, as inputs to the two 
Baud Rate Generators called BRGO and BRG1, and 
can be routed to the /RxC or /TxC pin. 


When CtrBypass is 1, both Counters are effectively 
bypassed. The signals from PORTO and PORT1 can 
be used directly as RxCLK and/or TxCLK, as inputs to 
the Baud Rate Generators, and can be routed to the 
/RxC and /TxC pins. When using this option, always 
program CTROSrc and CTR1Src as 00 to save power, 
because there is no reason for the Counters to run. 


RxC 


TxC 
PORTO 
/CLKO 
0 
PORT1 li : 
/CLK1 LHe a 
T | 1° MUX 





TxCHAR 
TxCMPLT p> Te 


MUX 


IOCRS:3 








Figure 18. A Model of the 16C32's Clocking Logic 


CTR1Sre CTROSrc praise BRGOSre DPLLSre TxCLKSre RxCLKSre 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


Figure 19. The Clock Mode Control Register (CMCR) 


CTRODIv Ale CVOK| DPLLDiv DPLLMode Sa encie| neseree | ancos BRGOE 
15 14 13 12 11 10 g 8 7 6 5 4 3 2 1 0 


Figure 20. The Hardware Configuration Register (HCR) 
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The Baud Rate Generators 


Two 16-bit down counters called BRGO and BRG1 
form the second stage of the IUSC's clock-generation 
logic. The BRGOSre and BRG1Sre fields in the Clock 
Mode Control Register (CMCR9-8 and CMCR11-10 
respectively) control what the BRGs' use as inputs: 


BRGnSRC B Clo ourc 
00 CTRO output or PORTO 
01 cCTR1 output or PORT] 
10 /RxC pin 
11 /Txc pin 


Each of the two Time Constant registers (TCOR and 
TC1R) contains a 16-bit starting value for the corres- 
ponding BRG down-counter. Zero in a Time Constant 
Register makes a BRG's output clock identical with its 
input clock; a value of one makes a BRG divide its 
input clock by two, and so on -- the all-ones value 
makes a BRG divide its input clock by 65,536 to 
produce its output clock. This flexibility of dividing by 
any value means that an-JUSC can derive many 
different baud rates from almost any input clock, 
unlike some competing devices that constrain the 
system designer to use specified crystal or oscillator 
values and constrain the available speeds to certain 
commonly-used baud rates. 


The BRGOE and BRG1E bits in the Hardware Config- 
uration Register (HCRO and HCR4 respectively; the 
"E" in the names is for "Enable") control whether each 
Baud Rate Generator runs or not. AO in one of these 
bits inhibits/olocks down-counting by the corres- 
ponding BRG, keeping the current value in the down 
counter unchanged despite transitions on the selected 
input clock. A 1 in one of these bits enables the 
corresponding BRG to count down in response to 
input clock transitions. 


When a Baud Rate Generator counts down to zero, it 
sets the BRGOL/U or BRGIL/U bit in the 
Miscellaneous Interrupt Status Register (MISR1 or 0). 
Once one of these bits is set, it stays set until 
software writes a 1 to the bit, to "unlatch’ it’. 


A BRG may or may not continue to operate after 
counting down to zero, depending on the BRGOS or 
BRG1S bit in the Hardware Configuration Register 
(HCR1 or WHCRS5 respectively; the "S" stands for 
"Single cycle"). AO in BRGnS causes BRGn to reload 
the TCn value automatically and continue operation, 
while BRGnS=1 makes BRGn stop when it reaches 0. 


Software can (re)load the value in the Time Constant 
register(s) into one or both BRG counters by writing a 
Load TCO, Load TC1, or Load TCO and TC1 com- 
mand to the RTCmd field of the Channel Command / 
Address Register (CCAR15-11), as described in the 
Commands section of Chapter 4. These commands 
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also restart a BRG that's in Single Cycle mode and 
has counted down to zero and stopped. 


The TCORSel bit in the Receive Interrupt Control 
Register (RICRO) and the TC1RSel bit in the Transmit 
Interrupt Control Register (TICRO) control what data 
the IUSC provides when software reads the TCOR 
and TC1R addresses. If a TCnRSel bit is 0, the IUSC 
returns the time constant value last written to TCn. At 
the time that a 1 is written to a TCnRSel bit, the IUSC 
captures the current value of the BRGn counter into a 
special latch, and thereafter returns the captured 
value from this latch when software reads the TCn 
address. Note that in order to obtain a series of 
relatively current values of a running BRGn, software 
has to write a 1 to the TCnRSel bit just before each 
time it reads the TCnR location. 


The output of either Baud Rate Generator can be 
used as RxCLK and/or TxCLK. It can be used as the 
reference clock input to the Digital Phase Locked 
Loop (DPLL) circuit, and it can be output on the /RxC 
or /TxC pin. ‘ 


When a Baud Rate Generator isn't used to make a 
serial clock, software can use it for other purposes 
such as protocol timeouts, and can program the IUSC 
to request an interrupt when it counts down to zero. 
Chapter 6 covers interrupts in detail, but to use BRG 
interrupts software should write 1's to the BRG1 |A bit 
and/or BRGO IA bit in the Status Interrupt Control 
Register (SICR1 and/or SICRO), as well as to the MIE 
and Misc IE bits in the Interrupt Control Register 
(ICR15 and ICRO). 


Introduction to the DPLL 


A Digital Phase Locked Loop (DPLL) circuit comprises 
the "third stage" of the IUSC's clock-generation logic. 
The DPLL is a 5-bit counter with control logic that 
monitors the serial data on RxD. The DPLLSrc field 
of the Clock Mode Control Register (CMCR7-6) 
controls which signal the DPLL uses as its nominal or 
reference clock: 


DPLLSre DPLL reference clock 
00 BRGO output 
O01 BRG1 output 
10 /RxC pin 
11 /TxC pin 


The DPLLDiv field of the Hardware Configuration 
Register (HCR11-10) determines whether the DPLL 
divides this reference clock by 8, 16, or 32 to arrive at 
its nominal bit rate, as follows: 


DPLLDiv Nominal DPLL Clock 
00 reference clock / 32 
01 reference clock.’/ 16 
10 reference clock / 8 
11 Reserved (/4 for CTR1) 


The 11 value cannot be used for DPLL operation, but 
if the DPLL isn't used, software can program this 
value together with writing a 1 to the CTR1DSel bit 
(HCR13) to operate CTR1 in “divide by four" mode. 


A later section describes the operation of the DPLL in 
greater detail, but for now it's sufficient to note that it 
samples the (typically encoded) data stream on RxD 
to produce separate receive and transmit outputs. 
These outputs are synchronized to the bit boundaries 
on RxD, and can be used as RxCLK and/or TxCLK 
and/or can be routed to the /RxC or /TxC pin. - 


TxCLK and RxCLK Selection 


The Transmitter can take its TxCLK from any of the 
sources described in preceding sections, under 
control of the TxCLKSre field of the Clock Mode 
Control Register (CMCR5-3): 


TxCLKSre Source of TxCLK 
000 No clock (xmitter disabled) 
001 /RxC pin 
010 /Txc: pin 
O11 Tx output of DPLL 
100 BRGO output 
101 BRG1 output 
110 PORTO or CTRO output 
111 PORT1 or CTR1 output 


Similarly, the Receiver can take its RxCLK from 
various sources, under control of the RxCLKSre field 
of the Clock Mode Control Register (CMCR2-0): 


RxCLKSre Source of RxCLK 
000 No clock (receiver disabled) 
001 /RxC pin 
010 /TxC pin 
011 Rx output of DPLL 
100 BRGO output 
101 BRG1 output 
110 PORTO or CTRO output 
111 PORTI1 or CTR1 output 


Clocking for Asynchronous Mode 


For asynchronous reception, transitions on RxCLK 
don't have to have any relationship to transitions on 
RxD. When the Receiver is searching for a start bit, it 
samples RxD in each cycle of RxCLK, which it divides 
by 16, 32, or 64 to determine the bit rate. After the 
Receiver finds the 1-to-0 transition at the beginning of 
each start bit, it counts off the appropriate number of 
RxCLK cycles to the middle of the bit cell. At this 
point it samples RxD to validate the start bit. If RxD 
has gone back to 1, the Receiver ignores the prior 
transition as line noise and goes back to searching for 
a start bit. If RxD is still 0, the Receiver accepts the 
start bit. Then it counts off 16, 32, or 64 RxCLK 
cycles to the middle of each subsequent bit of the 
character, and samples RxD at those times. 


For asynchronous transmission, if the Transmitter has 
been idle and software then provides it with data and 
enables it, it drives TxD from 1 to 0 for the Start bit at 
the falling edge on TxCLK that follows the latter of 
these two steps. It applies each subsequent bit to 
TxD after counting off 16, 32, or 64 TxCLK cycles. 
When sending successive async characters, the 
Transmitter waits for the stop bit length programmed 
in the two MSBits of the TxSubMode field of the Chan- 
nel Mode Register (CMR15-14), before driving TxD 
from 1 to 0 for a subsequent start bit. If these bits 
specify "shaved" operation, the Transmitter adjusts 
the stop bit length per the TxShaveL field of the 
Channel Control Register (CCR11-8). 


Synchronous Clocking 


Except in asynchronous operation, one cycle on 
RxCLK corresponds to one data bit on RxD, and one 
TxCLK cycle corresponds to one bit on TxD. In any of 
the synchronous modes, the clock used by the 
receiver to sample the data must be similar to the one 
used by the remote transmitter to send the data. 


The simplest way to ensure this is to use a separate 
wire to send the clock from one station's transmitter to 
the other station's receiver. But often cost or the 
nature of the serial medium prevents this -- for 
example, you can't send a separate clock over a 
telephone line. In such cases it is common practise to 
encode the data so that serial stream also includes 
clocking information. For such applications, the |IUSC 
can both encode transmitted data and decode 
received data in any of several popular formats. 


In addition, the IUSC's Digital Phase Locked Loop 
(DPLL) module can recover a synchronized RxCLK 
from the received data. While the DPLL can source 
TxCLK as well, such operation propagates some of 
the clock jitter from this station's receive path onto its 


_ transmit path, which may increase the error rate. 
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Stopping the Clocks 


CMOS circuits like those in the IUSC don't draw much 
power compared to older technologies, but their 
power requirements can be reduced still further if their 
clock signals are stopped when the circuits don't need 
to operate. Most of this power savings can be 
obtained by having the software disable RxCLK and 
TxCLK by writing zeroes to the RxCLKSrce and 
TxCLKSre fields (CMCR2-0 and CMCRS5-3). If the 
Counters and Baud Rate Generators are used, power 
consumption is reduced further if software disables 
them by writing zeroes to as many as possible among 
CTROSre, CTR1Src, BRGOSrc, and BRG1Src 
(CMCR13-12, CMCR15-14, CMCR9-8, and CMCR11- 
10). The ultimate in serial-side power savings is 
obtained by having external logic stop the input 
clock(s) on the /RxC and/or /TxC pins. 


When RxCLK is stopped, previously-received data 
can be read from the RxFIFO but RxD is ignored so 
that no further data will arrive. A final character will be 
available to the software and/or the Receive DMA 
controller if RxCLK runs for at least three cycles after 
its last bit is sampled from RxD. For HDLC/SDLC this 
means at least 3 RxCLKs after the receiver samples 
the last bit of a closing Flag. For Async it means at 
least 3 RxCLKs after the receiver samples the stop bit 
of the last character. 


TxCLK can be stopped after the last desired bit has 
gone out on TxD. This is 2 or 3 TxCLKs after the last 
bit has left the Transmit shift register (because of the 
Transmit encoding logic), which in turn occurs 1 or 2 
TxCLKs after the Transmitter sets the TxUnder bit 
(TCSR1). 


Data Formats and Encoding 


The IUSC's Transmitter and Receiver can handle data 
in any of the eight formats shown in Figure 21. The 


NRZB 


RxDecode field in the Receive Mode Register 
(RMR15-13) controls the format for the Receiver, and 
the TxEncode field in the Transmit Mode Register 
(TMR15-13) controls it for the Transmitter. The IUSC 
interprets both fields as follows: 


XMR15-13 Data Format 
000 NRZ 
001 NRZB 
010 NRZI-Mark 
Ol1l NRZI-Space 
100 Biphase-Mark 
101 Biphase-Space 
110 Biphase-Level 
111 Differential Biphase-Level 


NRZ mode doesn't involve any encoding: at the start 
of each bit cell the transmitter makes TxD low for a 0 
or high fora 1. NRZB mode is similar except that the 
transmitter and receiver invert the data: a low is a 1 
and a high is a0. 


| 


| | 
Biphase-Level | | 


DPLL TxCLK (all modes) 
DPLL RxCLK (NRZ modes) | 


DPLL RxCLK 


(Biphase modes) : 


| 
| 


Note: No assumption is made about the starting state of the serial data in this figure. 
As aresult, those encoding schemes that operate in terms of transitions rather than levels 
are shown with dual traces corresponding to their two possible starting states. 





Figure 21. Data Formats / Encoding 


In NRZI-Mark mode, at the start of each bit cell the 
transmitter inverts TxD for a 1 but leaves it unchanged 
for a0. In NRZI-Space mode, at the start of each bit 
cell the transmitter inverts TxD for a 0 but leaves it 
unchanged for a 1. 


None of these NRZ-type modes, by itself, guarantees 
transitions in the data stream. However, if the higher- 
level protocol can guarantee transitions often enough, 
then the DPLL can use these transitions to recover a 
clock from the data stream. By some method the 
protocol must eliminate long bit sequences without 
transitions in the data: successive zeroes for NRZ, 
NRZB, and NRZI-Mark and successive ones for NRZ, 
NRZB, and NRZl-Space. 


For example, NRZI-Space mode matches up well with 
HDLC and SDLC protocols, because the Transmitter 
inserts a extra zero into the data stream whenever the 
transmitted data would otherwise produce six ones in 
succession. Thus, there is at least one transition 
every seven bit times. 


The reliability of clock recovery from any kind of NRZ 
data stream depends on guaranteed transitions, on 
the transmitters and receiver's time bases being 
reasonably similar/accurate, and on fairly low phase 
distortion in the serial medium. Such schemes have 
the advantage that bits can be sent at rates up to the 
maximum switching rate (baud rate) of the medium. 


The four Biphase modes, on the other hand, provide 
highly reliable clock recovery and do not constrain the 
content of the data, but they limit the data rate to half 
the switching rate (baud rate) of the serial medium. 


See the waveform for Biphase-Mark mode in Figure 
21. This encoding scheme is also known as FM1. 
The transmitter always inverts the data at the start of 
each bit cell. At the midpoint of the cell it changes the 
data again to indicate a 1-bit, but leaves the data 
unchanged for a zero. In Biphase-Space mode 
(FMO) the transmitter always inverts the data at the 
start of each bit cell. In the middle of the cell it 
changes the data again for a zero-bit but leaves the 
data unchanged for a one-bit. In Biphase-Level 
mode (also called Manchester encoding), at the start 
of the bit cell the transmitter makes TxD high for a 
one-bit and low for a zero. It always inverts TxD in 
the middle of the cell. In Differential Biphase Level 
mode, at the start of each bit cell the transmitter 
inverts TxD for a zero but leaves it unchanged for a 
one. It always inverts TxD in the middle of the cell. 


More About the DPLL 


While the Transmitter and Receiver must be program- 
med for the particular serial format to be used, the 
DPLL only needs to know the general category of 
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encoding on RxD, in the DPLLMode field of the 
Hardware Configuration Register (HCR9-8): 


DPLLMode DPLL Operation/Decoding 
00 DPLL disabled 
01 Any NRZ mode 
10 Biphase-Mark or -Space 
11 Either Biphase-Level mode 


In any of the NRZ modes, transitions on RxD occur 
only at the boundaries between bit cells. The DPLL 
synthesizes a clock having falling edges at bit cell 
boundaries and rising edges in the middle of the cells. 
The Transmitter changes TxD on falling edges of 
TxCLK and the Receiver samples data on rising 
edges of RxCLK. 


In the Biphase-Mark and Biphase-Space encodings, 
there is always a transition at the boundaries between 
active data bits, and there may or may not be a 
transition at the center of each bit cell. The DPLL 
generates a receive clock having its falling edge 1/4 of 
the way through the bit cell, and its rising edge at the 
3/4 point. The Receiver determines each data bit 
from the state of RxD at rising edges of RxCLK and 
checks for "missing clocks" around falling edges. The 
DPLL generates a Transmit clock that is the same as 
in NRZ modes. The Transmitter complements the 
state of TxD at each falling edge of TxCLK, and may 
or may not change TxD at rising edges depending on 
the current data bit. 


In the Biphase-Level and Differential Biphase-Level 
encodings, there is always a transition at the midpoint 
of each active data bit, and there may or may not be 
transitions at the boundaries between bit cells. The 
DPLL generates clocks as for Biphase-Mark and 
Space, but must know the difference between those 
modes and these to do so. The Receiver determines 
each data bit from the state of RxD at falling edges of 
RxCLK and checks for "missing clocks" around rising 
edges. The Transmitter may or may not change TxD 
at falling edges of TxCLK, depending on the current 
data bit. It always inverts TxD at rising edges. 


The DPLL does not include logic to track the clock 
frequency of the remote end in a long-term manner. 
Rather it is a counter that is affected by transitions on 
RxD, and uses the reference clock to make bit 
clocking that is more or less synchronized to these 
transitions. Figure 22 shows the IUSC's Channel 
Command/Status Register. Its DPLLEdge field 
(CCSR9-8) provides further control over DPLL 
operation. For most applications, this field should be 
00, in which case the DPLL resynchronizes its counter 
on both rising and falling edges on RxD. 





RCCF | RCCF | Clear ; DPLL | DPLL | DPLL 
Ovflo | Avail | RCCF | Sync | 2Miss | 1Miss 
15 14 13 12 11 10 


DPLLEdge | On | Loop; Ctr TxResidue Reserved 
Loop | Send |Bypass 
9 8 7 6 5 4 3 2 1 0 


Figure 22. The 16C32's Channel Command/Status Register (CCSR) 


For NRZ applications in which one kind of edge is 
significantly more precise than the other, software can 
program the DPLLEdge field to 10 or 01, to make the 
DPLL ignore one kind of transition. One example of 
such an application is a serial bus with passive 
external pull-ups; in such a application, falling edges 
are more accurate than rising edges. If DPLLEdge is 
11, the DPLL never resynchronizes -- that is, it runs 
freely like CTRO and CTR1. 


Because the blocking of edges by DPLLEdge affects 
missing clock detection as well as resynchronization, 
for Biphase operation DPLLEdge should always be 
programmed as 00. 


In any NRZ mode, when the DPLL is in sync, it uses 
the selected nominal value (8, 16, or 32 cycles of its 
input clock) for counting off the next bit cell if a 
transition on RxD falls near the bit cell boundary. Ifa 
transition comes early it uses the nominal value minus 
1 for the next cell, while if a transition comes late it 
uses the nominal value plus one. In /16 and /32 
modes only, the DPLL uses the nominal value plus 
two for the next bit cell if a transition comes very late 
in a cell, and the nominal value minus two if a 
transition comes very early. 


In Biphase-Mark and Biphase-Space modes, when 
the DPLL is in sync it ignores "data" transitions in the 
second and third quarters of the bit cell, and 
resynchronizes to "clock" transitions in the fourth and 
first quarters of the cell. If a clock transition falls very 
close to the cell boundary, the DPLL uses the nominal 
value (8, 16, or 32) as the length of the next bit cell. 
Otherwise it uses the nominal value minus one if a 
clock transition comes early, or the nominal value plus 
one if a clock transition is late. 


In Biphase-Level and Differential Biphase-Level 
modes, when the DPLL is in sync it ignores “data’ 
transitions in the first and fourth quarters of the bit 
cell, and resynchronizes to "clock" transitions in the 
second and third quarters of the cell. If a clock trans- 
ition falls very close to the middle of the cell, the DPLL 
uses the nominal value (8, 16, or 32) as the length of 
the next bit cell. Otherwise it uses the nominal value 
minus one if a clock transition comes early, or the 
nominal value plus one if the transition is late. 


In an NRZ mode, if there's no transition in a bit cell the 
DPLL uses the nominal value (8, 16, or 32 clocks) as 
the length of the next bit cell. It also does this in 
Biphase modes, if there is no clock transition in a bit 


cell when the DPLL is in sync. In particular, in these 
cases the DPLL doesn't re-apply a correction from a 
previous bit cell. 


In Biphase modes, the CVOK bit in the Hardware 
Control Register (HCR12) controls whether the 
Receiver flags a single code violation as an error. lf 
CVOK=0, it sets the DPLL1Miss bit for a single code 
violation as described below. If CVOK=1, it doesn't 
report a single code violation in DPLL1Miss; use this 
setting when the protocol includes single code viola- 
tions aS normal occurrences, as in the 1533B mode 
that's described in Chapter 4. Regardless of CVOK, 
code violations in two consecutive bit cells, set the 
DPLL2Miss and DPLLDSync L/U bits and de- 
synchronize the DPLL. 


After software sets up the DPLL, three bits in the 
Channel Command/Status Register (CCSR) provide 
the operating interface. The logic enters a "fast sync 
mode" when software writes a 1 to the DPLLSync bit 
(CCSR12), or in a Biphase mode when it detects two 
consecutive missing clocks. In this mode, the next 
RxD transition (that's allowed by the DPLLEdge field) 
resynchronizes the DPLL counter and puts the DPLL 
“pack in sync". -. 


The DPLLSync bit in the Channel Command/Status 
Register (CCSR12) reads as 1 if the DPLL is in sync. 
The DPLL2Miss bit (CCSR11) reads as 1 if the DPLL 
is in a Biphase mode and has detected missing clocks 
in two consecutive bit cells. The DPLL1Miss bit 
(CCSR10) reads as 1 if the DPLL is in a Biphase 
mode, the CVOK bit (HCR12) is 0, and the DPLL has 
detected a missing clock in at least one cell. Once 
DPLL2Miss or DPLLIMiss is 1, it continues to read 
that way until software writes a 1 to it. 


Writing a 0 to any of DPLLSync, DPLL2Miss, or 
DPLL1Miss has no effect on the DPLL logic. 


The lUSC sets the DPLLDSynce L/U bit when it loses 
sync in a Biphase mode. This bit is similar to 
DPLL2Miss in that once it's set, it stays that way until 
software writes a 1 to the bit to "unlatch" it. Chapter 6 


— explains how to program the IUSC so that it interrupts 
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the host processor when it sets DPLLDSync. 


CTSMode 


15 14 


DCDMode TxRMode RxRMode TxDMode | TxCMode RxCMode 
13 12 1 10 9 8 7 6 5 4 3 2 1 0 


Figure 23. The Input/Output Control Register (IOCR) 


The RxD and TxD Pins 


In some sense these are the most important pins on 
an I|USC. Typically they carry the serial input to the 
Receiver and the serial output of the Transmitter 
respectively. Figure 23 shows the |/O Control 
Register. Its TxDMode field (IOCR7-6) allows soft- 
ware to control the function of TxD: 


TxDMode Function of the TxD pin 
00 Totem-pole Transmitter output 
01 High-impedance state 
10 Low output 
11 High output 


Software can use the ability to drive TxD low to 
generate a Break condition in Asynchronous appli- 
cations. The duration of such a Break is fully under 
software control. 


The ability to put the TxD pin in a high-impedance 
state allows software to use the IUSC in "serial bus" 
schemes that include multiple senders on the same 
signal line. (But note that the TxDMode field resets to 
00, so that the IUSC drives TxD after a Reset until the 
software programs TxDMode to 01.) The ability for 
direct programmable control over the TxD pin allows 
software to "bit-bang" unusual/occasional serial proto- 
col requirements, while keeping the |USC's full power 
for more standard and everyday communications. 


The RTMode field of the Channel Command/Address 
register (CCARQ-8) controls the relationship between 
the Transmitter and the Receiver and thus between 
the TxD and RxD pins. It is encoded as follows: 


RTMode Operation 

00 Normal operation: the 
Transmitter and Receiver are 
completely independent. 
Echo mode: the state of the 
RxD pin is copied directly 
onto the TxD pin. Data from 
the Transmitter is ignored. 
Pin Controlled Local Loop: 
the data from the TxD pin, as 
determined by the TxDMode 
field (IOCR7-6), is routed to 
the Receiver rather than the 
data from RxD. If TxDMode 
specs TxD as high impedance, 
the Receiver can take its 
input from a remote source 
via TxD rather than RxD. 


01 


10 
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11 Internal Local Loop: the data 


from the Transmitter is 
routed to the Receiver rather 
than the data from RxD, 
regardless of the setting of 
the TxDMode field (IOCR7-6). 


Edge Detection and Interrupts 


Software can program the IUSC to detect rising 
and/or falling edges on the /CTS, /DCD, /TxC, /RxC, 
/TxREQ, and /RxXREQ pins, and to interrupt when 
such events occur. Figure 24 shows that the Status 
Interrupt Control Register (SICR) includes separate 
Interrupt Arm (IA) bits for rising and falling edges on 
each of these pins. (Chapter 6 describes the IUSC's 
interrupt features in detail.) A 1 in one of these bits 
makes the IUSC detect that kind of edge, while a 0 
makes it ignore such edges. This edge detection and 
interrupt mechanism operates without regard for 
whether the various pins are programmed as inputs or 
outputs in the !/O Control Register (IOCR). 


When the IUSC detects an edge that's enabled in the 
SICR, it records the event in an internal “edge 
detection latch" for that input. This latch is not directly 
accessible in the IUSC's register map. Instead, as 
shown in Figure 25, the Miscellaneous Interrupt 
Status Register (MISR) includes two bits for each of 
these six pins, one called a "Latched/Unlatch" or L/U 
bit, and the other being a "data bit" that has the same 
name as the pin itself. 


A hardware or software Reset sequence clears all the 
L/U bits to zero. While the L/U bit for a pin is 0, the 
associated data bit reports and tracks the state of the 
pin in a "transparent" fashion, with a 1 indicating a low 
and a 0 indicating a high. 


Whenever a pin's L/U bit is 0 and its internal edge- 
detection latch is set, the IUSC sets the L/U bit to 1, 
clears the detection latch, and sets the |/O Pin 
Interrupt Pending (IOP IP) bit. IOP IP can be read 
and cleared (and if necessary set) in the Daisy Chain 
Control Register (DCCR1). Chapter 6 describes how 
the I/O Pin Enable and Master Interrupt Enable bits 
determine whether the IP bit actually results in an 
interrupt request to the processor, 










TxCDn | TxCUp | RxRDn| RxRUp| TxRDn | TxRUp |DCDDn| DcDUp| CTSDn|CTSUp| ROS | PPLL | gras | BRGo 
IA IA IA IA IA IA IA IA IA IA ae mae IA IA 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Figure 24. The Status Interrupt Control Register (SICR) 


RCC | OPLL | ara | BRGO 
RxCL/U| /RxC |TxCL/U] /TxC |RxRL/U\/RxREQ|TxRL/U!/TxREQ|DCDL/U| /DCD |CTSL/U} /CTS | Under | DSync L/U L/U 
L/U L/U 
15 14 13 12 11 10 9 8 7 6 5 4 2 1 0 


3 
Figure 25. The Miscellaneous interrupt Status Register (MISR) 










While an L/U bit is 1, the state of the associated data * for isochronous mode, /DCD should set up low to 


bit is frozen (latched). These two bits remain in this the rising edge of RxCLK at which the receiver 
state, regardless of further transitions on the pin, until samples the start bit on RxD. 

software writes a 1 to the L/U bit. This clears the L/U * for monosync, bisync, and transparent bisync, 

bit to O and "opens" the data bit to once again report /DCD should set up low to the rising edge of 

and track the state of the pin, at least for an "instant’. RxCLK that precedes the one at which the 

lf one or more enabled transitions occurred while the receiver samples the first bit of the last sync 

L/U bit was set, then L/U is set again right after pattern before the message. 

software writes the 1 to it. * — for HDLC/SDLC mode, /DCD should set up low to 
Writing a 0 to an L/U bit has no effect, and the IUSC the rising edge of RxCLK at which the receiver 
ignores data written to the data bits. samples the ending 0 of the last Flag before the 


: fe frame. 
One mode in which software can use this logic is to 


read the MISR, then immediately write back what it . OCDMode=01 identifies the /DCD pin as an input from 
has read. The software should then look for 1's in any external sync detection logic. Software typically 
and all "interesting" L/U bits, and process/handle all | programs this value in conjunction with programming 
such changes without rereading the MISR. To obtain the RxMode field of the Channel Mode Register 
the current state of one of these pins, regardless of | (CMR3-0) with 0001 for External Sync operation or 
the L/U bit, software can write a 1 to the L/U bit and 1001 for 802.3 (Ethernet) operation. For External 


then immediately read back the MISR. Sync mode, external logic should drive the /DCD pin 
low during the RxCLK cycle after the last bit in the 
The /DCD Pin sync character. For 802.3 it should drive /DCD low 


, when carrier is detected -- a figure in Chapter 4 shows 
The DCDMode field of the I/O Control Register ae Sand eee 
(|OCR13-12) controls the function of this pin: that the timing relationship to RxD isn't critical but 


DCDMo F } € the /DCD there should be at least 58 of the 64 alternating bits 


00 Low-active Rx Carrier input that precede the frame left. The Receiver starts 
01  Low-active Rx Sync input sampling RxD at the same rising edge of RxCLK at 
10 Low output which it first samples /DCD low. If /DCD goes high 
11 High output during a received character, the Receiver completes 


receiving the character and transfers it to the Receive 
When DCDMode is 00, software can handle the g ; WV 


Carrier indication all by itself. Or, the /DCD signal can PIES Delore Golng:nachye: 

enable and disable the Receiver in hardware if soft- | Sync conditions generated internal to the IUSC are 
ware also programs the RxEnable field of the Receive not output on this pin as on certain predecessor 
Mode Register (RMR1-0) to 11. Inthe latter case, the | devices, but can be output on either the /RxC or 
Receiver starts assembling a character only when PORTS pin as described later. 

/DCD is low; if /DCD goes high during a received The /DCD pin can alternatively be used as a general- 
character, the Receiver aborts/discards it. Figure 26 purpose output. To do this, simply program 
shows how the required relationship between /OCD pcpMode to 10 to make the IUSC drive IDCD low, 
and RxD varies depends on the Receiver mode: and to 11 to drive the pin high. For such an appli- 
* for async, nine-bit, and ACV/1553B modes, /DCD cation the designer may want to connect a pull-up or 


should set up low to the rising edge of RxCLK pulldown resistor to the /DCD pin, because the IUSC 
after the falling edge at which the receiver first will not drive the pin from the time /RESET goes low 
samples the start bit on RxD. until the software programs DCDMode to 10 or 11. 
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/DCD | 


RxD (Async, 9-bit, 
ACV/1553B) 









start bit ; 





\ start | 

RxD (Isochronous) bit : 

RxD (Monosyne, Bisync, | {st bit rest of (last) 

Transparent Bisync) : of Sync Sync character(s) 
{ esto | o V istbit 

RxD (HDLC) 0111111 of Flag j\ of Frame 


Figure 26. /DCD Auto-Enable Timing 








Software can program the IUSC to interrupt the host the Transmit Mode Register (TMR1-0). In the latter 
processor on either or both edges on /DCD, as_ case, the Transmitter will start sending a character 
described in the preceding section. Typically such = only when /CTS is low. As shown in the following 
interrupts would be used when /DCD is an input, that Figure, if the Transmitter is otherwise "ready to go" 
is, wnen DCDMode is 00 or 01. Software should write. when /CTS goes low, the first bit active bit on TxD will 
a 1 tothe DCDDn IA bit in the Status Interrupt Control begin at the falling edge of TxCLK that is 4.5 clock 
Register (SICR7) to make the IUSC detect falling periods after the rising edge of TxCLK at which the 
edges on /DCD, and write a 1 to DCDUp IA (SICR6) ‘Transmitter first samples /CTS low. 

to make it detect rising edges. 


As described in the preceding section, the DCDL/U bit ets | \ 


(MISR7) is 1 if the IUSC has detected an enabled 
edge, until software writes a 1 to the bit to clear it. TxCLK ap a 
The /DCD bit (MISR6) reflects the state of the /DCD (/TxC) < en > 





pin transparently while DCDL/U is 0, but is frozen TxD «(Listas 
while DCDL/U is 1. MISR6=0 indicates a high on the . i 

pin, and 1 Indicates a low. Figure 27. /CTS Auto-Enable Timing 

The /CTS Pin If /CTS goes high during a transmitted character in an 
The CTSMode field of the I/O Control Register | asynchronous mode, the Transmitter finishes sending 
(1OCR15-14) controls the function of this pin: the character before going inactive. In the same 
CTSMode Function of the /CTS pin situation in a synchronous mode, the Transmitter 


0x Low-active Clear to Send input terminates transmission immediately. 


=e; how OUrRUE The /CTS pin can alternatively be used as a general- 

11 High output purpose output. To do this, simply program CTSMode 
When CTSMode is 00 or 01, software can handle the =‘ to 10 to make the IUSC drive /CTS low, and to 11 to 
Clear to Send input all by itself. Alternatively, the | make it drive the pin high. For such applications the 
/CTS input can enable and disable the Transmitter in designer may want to connect a pull-up or pulldown 
hardware, if software writes 11 to the TxEnable field of 
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resistor to the /CTS pin, because the IUSC won't drive 
the pin from the time /RESET goes low until the 
software programs CTSMode to 10 or 11. 


Software can program the IUSC to interrupt the host 
processor on either or both edges on /CTS, as 
described in the earlier section Edge Detection and 
Interrupts. Typically such interrupts would be used 
when /CTS is an input, that is, when CTSMode is 00 
or 01. Software should write a 1 to the CTSDn IA bit 
in the Status Interrupt Control Register (SICR5) to 
make the IUSC detect falling edges on /CTS, and 
write a 1 to CTSUp IA (SICR4) to make it detect rising 
edges. 


As described in Edge Detection and /nterrupts, the 
CTSL/U bit (MISRS5) is 1 if the IUSC has detected an 
enabled edge, until software writes a 1 to the bit to 
clear it. The /CTS bit (MISR4) reflects the state of the 
/CTS pin transparently while CTSL/U is 0, but is 
frozen while CTSL/U is 1. MISR4=0 indicates a high 
on the pin, and 1 indicates a low. 


The /RxC and /TxC Pins 


Figure 18 (near the start of this chapter) shows the 
|USC's options for the function of its /RxC and /TxC 
pins. The RxCMode field in the Input/Output Control 
Register (IOCR2-0) controls the function of /RxC: 


RxCMode Function of the /RxC pin 


000 /RxC is an input 

001 /RxC outputs RxCLK 

010 /RxC outputs Rx character clock 
011 /RxC outputs /RxSYNC 

100 /RxC carries the BRGO output 
101 /RxC carries the BRG1 output 
110 /RxC carries PORTO or CTRO out 
111 /RxC carries the DPLL Rx output 


while the TxCMode field (lIOCR5-3) controls the 
function of the /TxC pin: 


TxCMode Function of the /TxC pin 
000 /TxC is an input 
001 /TxC outputs TxCLK 
010 /TxC outputs Tx character clock 
O11 /TxC outputs "Tx Complete" 
100 /TxC carries the BRGO output 
101 /TxC carries the BRG1 output 
110 /TxC carries PORT1 or CTR1 out 
111 /TxC carries the DPLL Tx output 


Some of these possible outputs need further descrip- 
tion. An IUSC drives the Receive character clock 
high for one RxCLK period as it transfers each 
character from the Receive shift register to the 
Receive FIFO. Similarly, it drives the Transmit 
character clock high for one TxCLK period each time 
it transfers a character from the Transmit FIFO to the 
Transmit shift register. The /RxSYNC output goes low 
for one RxCLK cycle each time the Receiver recog- 
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nizes a Sync or Flag sequence. The Tx Complete 
output is suitable for controlling a driver on TxD. It is 
low from the start of the first active bit of a sequence 
of one or more consecutively-transmitted characters, 
through the end of the last bit of the sequence. The 
BRG and CTR outputs are square waves. The DPLL 
outputs were shown earlier in this chapter. 


While it's not very useful to use a high-speed free- 
running clock as a source of interrupt events, for other 
uses of /RxC and /TxC software can program an IUSC 
to interrupt the host processor on either or both edges 
on these pins, as described in the earlier section Edge 
Detection and Interrupts. Typically such interrupts 
would be used for an input pin, that is, when 
RxCMode or TxCMode is 00 or 01. Software should 
write a 1 to the RxCDn IA or TxCDn IA bit in the 
Status Interrupt Control Register (SICR15 or SICR13) 
to make an |IUSC detect falling edges on /RxC or 
/TxC, and write a 1 to RxCUp IA or TxCUp IA 
(SICR14 or SICR13) to make it detect rising edges. 


As described in Edge Detection and Interrupts, the 
RxCL/U or TxCL/U bit (MISR15 or MISR13) is 1 if the 
IUSC has detected an enabled edge, until software 
writes a 1 to the bit to clear it. The /RxC or /TXC bit 
(MISR14 or MISR12) reflects the state of the pin 
transparently while the L/U bit is 0, but is frozen while 
the L/U bitis 1. AQ in MISR14 or MISR12 indicates a 
high on the pin, and 1 indicates a low. 


The /RXREQ and /TXREQ Pins 


The predecessor USC and MUSC devices provided 
separate /RxREQ and /TxREQ outputs for signalling 
an off-chip DMA controller when the Transmit and 
Receive FIFO's were in a programmed degree of 
"readiness" for DMA data transfer. They also 
provided /RxACK and /TxACK inputs by which the 
external DMA controller could signal that a “flyby’ 
DMA transfer was occurring. 


The IUSC includes internal Request and Acknowledge 
connections between its. serial controller and 
integrated DMA channels. Therefore there's little 
need for such pins, and in fact there are no ACK pins. 
The /RxREQ and /TxREQ pins survive for testing 
reasons, and can be used in applications as general 
/O's under control of the RxRMode and TxRMode 
fields of the I/O Control Register (IOCR9-8 and 
IOCR11-10 respectively): 


XxXRMode Function of /XxREQ pin 
00 Input pin 
Ol DMA Request output (or 
Interrupt Request) 
10 Low output 
11 High output 


Note that software doesn't have to program these 
fields as 01 in order to use the IUSC's DMA channels. 


Software can program an IUSC to interrupt the host 
processor on either or both edges on these pins, as 
described in the earlier section Edge Detection and 
Interrupts. Typically such interrupts would be used for 
an input pin, that is, when RxRMode or TxRMode is 
00. Software should write a 1 to the RxRDn IA or 
TxRDn IA bit in the Status Interrupt Control Register 
(SICR11 or SICR9) to make the IUSC detect falling 
edges on /RxREQ or /TxREQ, and should write a 1 to 
RxRUp IA or TxRUp IA (SICR10 or SICR8) to make it 
detect rising edges. 


As described in Edge Detection and Interrupts, the 
RxRL/U or TxRL/U bit (MISR11 or MISR9) is 1 if the 
lUSC has detected an enabled edge, until software 
writes a 1 to the bit to clear it. The /RxR or /TXR bit 
(MISR10 or MISR9) reflects the state of the pin trans- 
parently while the L/U bit is 0, but is frozen while the 
L/U bit is 1. AO in MISR10 or MISR9 indicates a high 
on the pin, and 1 indicates a low. 


The IUSC doesn't provide /RxACK and /TxACK pins, 
and so its Transmitter and Receiver cannot be used 
with an external "flyby" DMA controller. The fields 
associated with these pins in predecessor devices, 
HCR7-6 and HCR8-2, are not used in the IUSC. 


The Port Pins 


These eight pins can be individually programmed to 
be general purpose inputs or outputs. Alternatively, 
seven of the eight can carry a specific, dedicated input 
or output signal. Regardless of the directions and 
roles of the various pins, transitions on all eight are 
latched by the IUSC. Host software can read this 
latched status from the Port Status Register (PSR). 
Unlike the pins described in earlier sections, trans- 
itions on PORT7-0 cannot make the IUSC interrupt 
the host processor. 


Figure 28 shows the Port Control Register (PCR). It 
includes eight PnMode fields, each of which 
determines the use of one PORT pin: 
PnMode Function of PORTn pin 

00 General purpose input 

01 Dedicated I/0 

10 Low output 

11 High output 


The "dedicated |/O" function differs for each pin: 
PORT7 Tx Complete output 

PORT6 /FSYNC input 

PORT5 /RxSYNC output 

PORT4 Tx Time Slot Assigner Gate output 


PORT3 
PORT2 


Rx Time Slot Assigner Gate output 
Undefined, Reserved 

PORT1 Reference clock input to CTRI1 
PORTO Reference clock input to CTRO 


(Other sections of this chapter or Chapter 4 describe 
the utilization of each of these inputs and outputs.) 


On the 16C32, a hardware or software Reset makes 
all the PORT pins act as inputs. (On the 16C31, this 
didn't occur until software wrote the BCR.) As noted 
earlier for /DCD and /CTS, for Port pins that are out- 
puts, the system designer may want to connect a pull- 
up or pulldown resistor of about 10KOhms to the 
pin(s), to assure their state from when /RESET goes 
low to the time that software programs the PCR. 


Whether the various pins are inputs or outputs, the 
IUSC detects and latches transitions on all eight of 
them, and host software can read the latched status 
from the Port Status Register (PSR). Figure 29 
shows how this register includes two bits for each pin, 
one called PnL/U (for Latched/Unlatch) that can be 
both written and read back. The other bit of each pair 
is called /Pn and can only be read, which is to say, the 
IUSC ignores data written to the /P7-0 bits. 


After software writes a 1 to a particular PnL/U bit, the 
PnL/U bit reads back as a 0 and the associated /Pn bit 
reflects the state of the corresponding PORTn pin at 
the time of the write operation. After a Reset PnL/U is 
0 and /Pn reflects the state of the pin when /RESET 
went high. A 0 in a/P7-0 bit corresponds to a high on 
the associated pin, and a 1 corresponds to a low. 


The PnL/U bit remains 0, and /Pn does not change, 
until the I|USC detects a rising or falling transition on 
the associated PORTn pin. After such a transition, 
PnL/U reads back as 1 and /Pn reads as 0 for a rising 
edge and 1 for a falling edge. The two bits remain in 
this state, regardless of further transitions on the 
PORTn pin, until host software writes a 1 to PnL/U. 


- This clears the PnL/U input bit to 0 and “unlatches" 


the transition-detecting logic for the pin, although the 
IUSC will set the L/U bit again immediately if one or 
more transitions occurred while it was set. Writing a 0 
to a PnL/U bit has no effect on the logic for that pin. 


One mode in which software can use the Port logic is 
to read the PSR and immediately write back what it 
has read. Software can then look for 1's in any and all 
"interesting" PnL/U bits, and process/handle all such 
changes without rereading the PSR. To obtain the 
current state of a PORTn pin, software can write a 1 
to its PnL/U bit and then immediately read the PSR. 





Figure 28. The Port Control Register (PCR) 





Figure 29. The Port Status Register (PSR) 


The Time Slot Assigners 


In applications such as ISDN and Fractional T1, a set 
of independent voice and data streams share a high 
speed link by means of time multiplexing. The |USC 
can send and/or receive such a data stream with the 
aid of its Transmit and Receive Time Slot Assigner 
logic (TTSA and RTSA). 


To use the IUSC in such an application, external logic 
must find the start point of (or at least a consistent 
point in) each cycle of the total data stream, and 
signal the IUSC when this point occurs, using a 
"Frame Sync" pulse on the PORT6//FSYNC pin that is 
low for one period of RxCLK and/or TxCLK. Both the 
Receive and Transmit Time Slot Assigners use this 
pulse. This means that if both the Receiver and 
Transmitter are operating simultaneously in a Time 
Slotted application, they must both be operating in 
(different parts of) the same overall data stream. This 
also means that RxCLK and TxCLK must come from 
the same source. 


Figure 30 shows how the Time Slot Assigners. deter- 
mine when to start receiving and/or transmitting in 
each cycle. After sensing the /FSYNC pulse, the 
RTSA waits for a number of RxCLK cycles (bit times) 
that's determined by the RTSASlot and RTSAOffset 
fields in the Receive Interrupt Control Register 
(RICR). Specifically, it waits for this many RxCLK 


RxCLK or 
TxCLK 


cycles (bits): 8 times the value in RTSASlot, plus the 
value in RTSAOffset. 


Unless both fields are zero, the RTSA blocks RxCLKs 
to the Receiver for this number of bits. Then it allows 
RxCLK to reach the Receiver for the number of con- 
secutive bytes/octets/slots programmed into the 
RTSACount field in RICR. That is, it allows 
8(RTSACount) RxCLKs to reach the Receiver. Figure 
31 illustrates these points. (A zero in the RTSACount 
field disables the whole RTSA feature.) Then the 
RTSA again blocks RxCLKs to the Receiver until after 
the next pulse on /FSYNC. 


The net result of this clock-gating is that the IUSC can 
receive up to 15 consecutive bytes/octets out of each 
cycle on the serial link. This data can start at any 
point within the first 128 octets of each cycle. The 
TSAs also allow for possible delays in sensing and 
signalling the frame sync. 


In ISDN circles it seems to be common parlance to 
refer to the octets in each frame as numbered "slots" 
starting at 0. Given this definition of "slot number", if 
the frame sync detection logic is such that /FSYNC 
will be sampled low in the bit time before RxD should 
be sampled for the first bit of the first slot, then 
RTSAOffset should be programmed with zero and 
RTSASlot should be programmed with the slot num- 
ber of the first octet that should be received. 


a 


/FSYNC (PORT6) 


xTSAOffset=0, 
xTSASlot=0 


xTSAOffset>0, 
xTSASlot=0 


xTSAOffset=0, 
xTSASlot>0 


xTSAOffset>0, 
xTSASlot>0 





ist Bit Rcved 

or Xmitted 
(xTSAOffset) bits ist Bit Reved 
or Xmitted 
8*(xTSASlot) Bits ist Bit Reved 
or Xmitted 


(xTSAOffset) bits 8*(xTSASlot) Bits 


1st Bit Reved 
or Xmitted 


Figure 30. Start of Received or Transmitted Data in a TSA Application 
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TxCLK 
Sp} 
/IFSYNC | 
(PORT6) 


8*(xTSACount) Bits 


RxD or 
TxD 


Xmit Gate (PORT4) or 
Rev Gate (PORTS) 


Figure 31. Length of Received or Transmitted Data in a TSA Application 






Otherwise, call the "Frame Sync delay" one if /FSYNC §PORT4 pin. Figure 31 shows how this signal goes 
will be sampled low in the same bit time that the first | low while the TTSA is enabling the Transmitter in each 
bit of the first slot is available on RxD, two if /FSYNC frame. There is also a similar facility by which the 
is low in the bit time after the first bit appears on RxD, =RTSA's low-active Receive Gate signal can be output 
and so on up through the maximum value of seven if onthe PORTS pin, but the application of this signal is 
/FSYNC is low six bit times after the first bit of the first | less obvious. As already noted in the section on the 
slot appears on RxD. In these cases, the first slot | PORT pins, the P4Mode and/or P3Mode fields of the 
cannot be received: program the RTSAOffset field Port Control Register (PCR9-8 and/or PCR7-6 
with eight minus the "Frame Sync delay", and _ respectively) should be 01 to enable these options. 
program RTSASlot with the slot number of the first 

octet that should be received, minus one. Programming the Time Slot Assigners 


Figure 30 applies equally to the transmit side: the There is an intentional vagueness in the preceding 
TTSA similarly blocks TxCLKs to the Transmitter for description of the Time Slot Assigner control fields as 
the number of TxCLK cycles programmed in the being "in" the Receive and Transmit Interrupt Control 
TTSASIlot and TTSAOffset fields in the Transmit Registers (RICR and TICR). These two registers are 
Interrupt Control Register (TICR). somewhat more complex than other IUSC registers -- 
| this section describes how to access the TSA fields. 
After blocking TxCLKs for 8(TTSASlIot) + ~ lelds 


(TTSAOffset) bits, the TTSA allows TxCLK to reach Figure 32 shows how the less-significant byte of both 
the Transmitter for the number of consecutive the RICR and TICR contains fixed data, but any of five 
bytes/octets/slots programmed into the TTSACount different internal registers can be selected as the 
field in the Transmit Interrupt Control Register (TICR). | More-significant byte of each register. At the first 
That is, it allows 8(TTSACount) TxCLKs to reach the __ [evel of data structure, four of the commands that can 
Transmitter, as shown in Figure 31. (As for the be written to the RCmd field of the Receive Command 
receive side, zero in the TTSACount field disables the / Status Register (RCSR15-12) select the contents of 
whole TTSA feature.) Then the TTSA again blocks RICR15-8. Similarly, four of the commands that can 


TxCLKs to the Transmitter until after the next pulse on be written to the TCmd field of the Transmit 
/FSYNC. Command / Status Register (TCSR15-12) select the 
. contents of TICR15-8. The encoding of both sets of 
Thus, symmetrically with the receive side, the IUSC commanas is the same: 

can transmit up to 15 consecutive bytes/octets/slots in xCmd Contents of xICR15-8 

each cycle on the serial link. This data can start at 0100 xTSA data 

any point within the (first) 128 octets of each cycle, 0161: “Chevenk. xPIFOO Devel 

and the TTSA allows for possible delays in sensing 0110 xFIFO Level for Interrupt 


ane signaling tne wane SYN: 0111 xFIFO Level for DMA Request 

Since the IUSC maintains output drive on TxD (where "x" stands for either "R" or "T"). The other 
throughout each cycle on the serial link, this kind of —_gptions will be discussed in subsequent chapters. For 
time-multiplexed environment requires an external = oy, purposes it's sufficient to note that "TSA data" can 


driver with an enable/disable input. The IUSC can be read and written as xICR15-8 if the 0100 command 
provide the required "Transmit Gate" signal on the 
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has been written to xSCR15-12 more recently than 
0101, 0110, or 0111. The IUSC resets to reading the 
Current FIFO level in both the RICR and TICR. 


Figure 32 also shows how a second level of data 
structuring determines the meaning of "TSA data". 
For write operations, the bit written in the "bit 8" 
position selects the destination of the data: 
XICR8 value Destination of xICR15-9 

QO xICR15-9 --> xTSASlot 

1 xXxICR15-13 --> xTSAOffset 

1 xXxICR12-9 --> xTSACount 


Reading "TSA data" from RICR or TICR always yields 
the xTSASlot value, with the LSBit of the MSByte 
equal to zero. 


In summary, to set up xTSA, first write the 0100 
command to the xCmd field of the xSCR. Then write 
the xTSASlot value to the MSByte of xICR with the 
LSBit of the byte equal to 0. Finally, write the 
xTSAOffset and xTSACount values to the MSByte of 
xICR with the LSBit of the byte equal to 1. 


RICR or TICR 


If the last value In the range 
0100-0111, written to the "command" 
fleld of the RSCR or TSCR was: 


0100 


Then the following data can be 
accessed In the MS byte 
of RICR or TICR: 


Read or Write "TSA data" 


| Read the # of empty entries in the TxFIFO, 
or the # of rcved bytes In the RxFIFO 


Read or Write the # of empty TxFIFO entries, 
or the # of rcved characters in the RxFIFO, 
at which to request interrupt 


Read or Write the # of empty TxFIFO entries, 
or the # of rcved characters in the RxFIFO, 
at which to request DMA transfer 


Ifthe LSB ofthe: 
"TSA data" written Is: : 


Then the rest of the "TSA data" 
written should be as follows: 


| RTSASIot or Pa 
TTSASlot 


{ RTSAOffset or| RTSACount or 
TTSAOffset TTSACount 
Reading "TSA data" always ylelds this byte 
Figure 32. Structure of the RICR and TICR 








Notes: 


4. Serial Modes and Protocols 


The main advantage of USC family members is that 
they can communicate in many different modes and 
serial protocols. This, in turn, makes for more flexible 
and capable products for Zilog's customers. This 
chapter describes how to set up and use the IUSC in 
its various modes of serial operation. These modes 
can be classified into three major categories: asynch- 
ronous, character-oriented synchronous, and _bit- 
oriented synchronous protocols. 


Asynchronous Modes 


These protocols date back to when the first teletype- 
writers were succeeding Morse code, although there 
have been various changes since. Figure 32 shows 
how a Start bit precedes each character in async 
communications, and that so-called stop bits separate 
characters. A start bit is a period of space/zero that's 
the same length as each following data bit. Each stop 
bit is a period of mark/one having a nominal minimum 
duration of one bit time. (The IUSC and other devices 
offer the ability to "shave" stop bits to less than a bit 
time.) In most forms of async, the falling edge 
between a stop bit and the next start bit can come any 
time after this minimum stop bit duration. In other 
words, the length of the stop bit does not have to be 
any particular multiple of the nominal bit time. 


To handle this variability in the length of stop bits, 
asynchronous receivers "oversample" the received 


Start 
Bit 


5 to 8 data bits, 
plus optional parity bit 


serial data at some multiple of the nominal bit fre- 
quency. Software can set up the IUSC to do this at 
16, 32, or 64 samples/bit. When a Receiver is waiting 
for a start bit and successive samples reveal a falling 
edge, it typically samples again one-half bit time later, 
to validate the start bit. If the serial data is still 
space/zero, the receiver then samples the following 
data bits and stop bit at their nominal centers after 
that. If the hardware samples the stop bit as space/ 
zero, the associated character is invalid or at least 
highly suspect. 


Some async protocols check further for serial link 
errors by including a parity bit with each character. 
The transmitter generates such a bit so that the total 
number of 1-bits in the character is odd or even. The 
receiving station checks each parity bit. If it finds an 
incorrect one, it discards the character and/or notifies 
the operator(s) of the receiving and/or transmitting ma- 
chine(s). But a single parity bit is not a very reliable 
checking method -- it can be easily deceived by errors 
that affect more than one bit. Few async applications 
actually check parity nowadays, although they may 
generate it just in case they find themselves talking to 
equipment that does. Where protection against line 
errors is important, some async applications may use 
block-oriented checking as described below for 
synchronous protocols. 


Start 
Bit 


Stop 
Bit 


E ha hn bth eee 
I I\ I\ [\ I (except for "Shaving") 


1/2 Bit Time 


Rever detects 
Falling Edge 


Rever samples Data 


(and Parity?) Bits 


Rever validates 
Start Bit 


All 1 Bit Time 


Rever checks 


Stop Bit 


Figure 32. Asynchronous Data 
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<—____—_—_———- Message ——-—————> 


SYN SYN 


May be SYN's, 


< (16) << (1 a<c (02) 12) >< Data Seas >—<— CRC —><— Mark, Space-—s>< SYN ~ SYNE, 





(16) (16) 


or Not Driven 


Figure 33. Character Orlented Synchronous Data 


The IUSC can handle a variety of options within 
"classic" async operation, plus several unique variants. 
In isochronous mode, the data format is similar to 
classic async, but external hardware supplies a bit- 
synchronized 1X clock instead of a 16x, 32x, or 64x 
clock. In Nine-Bit mode, an extra bit differentiates 
between "address" characters that select a particular 
destination on a multi-station link, and subsequent 
data characters. In Code Violation mode, a three-bit 
sequence that includes violations of the encoding 
mode replaces the start bit that precedes each 
character. (A primary use of Code Violation mode is 
to implement MIL-STD-1553B.) 


Character Oriented Synchronous Modes 


These protocols came into use after async, in an effort 
to get better line utilization by eliminating start and 
stop bits. In sync modes, characters follow one 
another directly on the serial link, each consisting of 
an agreed-upon number of bits and each bit having the 
same nominal length. Since bits and characters occur 
at regular intervals, the datacom hardware can 
typically handle higher bit rates because it doesn't 
have to oversample as in typical async applications. 
This effect combines with having fewer bits per 
character, to make synchronous operation substan- 
tially faster than async. 


In sync modes, "special" characters divide the data 
into "messages". Figure 33 shows how the transmitter 
sends some minimum number of agreed-upon "sync 
characters" between messages. When a synchronous 
receiver begins to receive a message, it typically starts 
in a "search mode" in which it samples successive bits 
into its serial-to-parallel shift register. It does this until 
the last N bits match a defined sync pattern. Then the 
Receiver enters a mode in which it simply captures 
each succeeding group of bits as a character. 


Most sync protocols require the receiving station to 
validate the sync pattern match. It can do this by 
checking whether the next character is another sync, 
an agreed-upon "start of message" character, or 
perhaps one of a small set of such characters. This 
validation can be done by software or by hardware. 


Almost all character-oriented synchronous protocols 
also define one or more characters, or sequences of 
characters, to mark the end of a message. Instead of 
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(or sometimes besides) parity checking on each 
character, synchronous protocols will typically include 
a checking code covering most or all the characters in 
each message. The transmitter accumulates and 
sends this code before or after the end-of-message 
character or sequence. Early sync protocols used a 
Longitudinal Redundancy Character (LRC) that was 
simply the parallel Exclusive Or of the characters in 
the message. Newer protocols use various kinds of 
Cyclic Redundancy Checking (CRC), which offer 
greater reliability in exchange for a somewhat more 
involved method of computation. Either kind of 
message checking can be computed by either 
hardware or software at the Transmitter and Receiver. 
The IUSC hardware can automatically generate and 
check various kinds of CRCs. 


Synchronous applications vary considerably in terms 
of the line state between messages. In half-duplex 
operation, each station typically stops driving the line 
after the end of a message. The other side then starts 
driving it to "turn the line around". In full-duplex point- 
to-point environments, a transmitter may send a 
stream of repeated Sync or Idle characters between 


messages. This maintains synchronization between 
itself and the remote receiver as to character 
boundaries. This avoids the need to send several 


sync characters before the start of the next message, 
when it becomes available for transmission. In other 
full-duplex environments, the line may be maintained 
at a constant Mark or Space between messages. 


While many modes have several variants, the top level 
of the IUSC's control hierarchy includes the following 
character-oriented synchronous modes. In Monosync 
mode, the hardware transmits or matches a sync 
character of eight bits or less. Software must handle 
further receive-sync validation. In Bisync mode the 
hardware transmits or matches a minimum of two sync 
characters. The two can be the same or different 
codes, each of eight bits or less. Transparent Bisync 
mode is similar to Bisync mode except that the prefix 
character Data Link Escape (DLE) precedes control 
characters. This allows the transmission of arbitrary 
"binary" data without conflict with the various control 
characters. Slaved Monosync mode applies only to 
the Transmitter, making it operate in conformance with 
the X.21 standard, such that it sends characters in 
byte-synchronism with those received. External Sync 


mode applies only to the Receiver, and leaves all 
sync-detection and framing control to external circuitry. 
An input signal simply enables the Receiver to 
assemble characters from the RxD line. 


The final character-oriented synchronous mode of the 
IUSC provides basic facilities for /EEE 802.3 (Ether- 
net) operation. At the start of a frame, the Transmitter 
generates, and the Receiver detects, a preamble 
consisting of alternating 0 and 1 bits ending with two 
1's in succession. Bi-phase-level data encoding must 
be selected in the Transmit and Receiver Mode 
Registers (TMR and RMR), as described in Chapter 3. 
External hardware must be provided to detect 
collisions and to signal the Transmitter when they 
occur. It also must signal the Receiver when a frame 
ends based on loss of carrier. Upon collision 
detection, "back-off" timing must be determined by 
external hardware or host processor software. 


Bit Oriented Synchronous Modes 


As_character-oriented synchronous protocols came 
into wider use in the 1960's and 70's, the number of 
characters having special significance for the 
hardware kept increasing. Hand in hand with this, the 
complexity of the required hardware processing and 
state machines rose drastically. Particularly trouble- 
some was data "transparency", the ability to transmit 
any kind of "binary" data without conflict with the many 
control characters used in these protocols. 


These problems might be less severe were they 
occurring today. But given the technology available in 


the 1960's, the proliferation of sync protocols was 
making it harder and harder to build general purpose 
datacom hardware. Instead, one had to build dedi- 
cated communications controllers for each protocol. 


Bit oriented synchronous protocols were a response to 
these problems. IBM's SDLC was the first one widely 
used; subsequent standardization efforts added 
several refinements in defining HDLC. These 
protocols simultaneously minimized the amount of 
required hardware support, while lifting all restrictions 
on the content of the data transmitted. Figure 34 
shows how in bit-oriented modes, frames are groups 
of sequential characters, each ending with a CRC 
code to verify its correctness as in character-oriented 
protocols. The difference lies in the Flag sequences 
used to begin, end, and separate frames. 


When a bit-oriented synchronous Receiver starts to 
receive a frame, it looks for a Flag sequence 
(01111110) just as a character-oriented synchronous 
Receiver looks for its sync character. While sending a 
frame, a bit-oriented synchronous Transmitter continu- 
ally checks whether any sequence of data bits could 
look like a Flag. It does this without regard for charac- 
ter boundaries. Whenever the data presented to a 
Transmitter includes a zero followed by five ones, the 
Transmitter adds an extra zero-bit after the fifth one- 
bit. | Correspondingly, a_ bit-oriented synchronous 
Receiver monitors the serial data stream within a 
frame; any time it sees 0111110, regardless of charac- 
ter boundaries, it deletes the trailing zero. 


May be Flags, 
Flag_y ¢ Mark, Space-p~— FlA9_pwe pata 
E) or Not Driven (7E) 


The Data actually sent will include: 
ee 


Extra 0-bit inserted by Transmitter, 
deleted by Receiver 


Figure 34. HDLC/SDLC Data 





This relatively simple technique allows transmission of 
any kind of data and assures uniqueness of the Flag 
sequence within the data stream. (Uniqueness is 
assured as long as line errors don't occur.) This 
makes for simpler hardware than with some character- 
oriented synchronous protocols, in that the hardware 
only has to recognize a few bit sequences. They 
include 0111111 for zero-bit-stuffing by a Transmitter, 
0111110 for bit removal by a Receiver, a Flag 
sequence, and finally an Abort sequence. An Abort is 
a zero followed by more consecutive ones than in a 
Flag (e.g., 7 or 15 ones). 


As mentioned in the previous chapter, SDLC/HDLC 
protocols match up well with NRZI-Space encoding to 
ensure data transitions for clock resynchronization. 
This is because the Transmitter inverts NRZl-space 
data for every O-bit and there are never more than five 
1-bits in succession within a frame. 


Finally, since the Flag-matching hardware operates 
without regard for character boundaries, bit-oriented 
synchronous protocols can handle frames that are any 
number of bits in length. (In character-oriented synch- 
ronous protocols, messages must be composed of an 
integral number of characters.) 


The IUSC can handle most variations of SDLC and 
HDLC protocols, since it leaves the details of almost 
all such variations to the host software. One variation 
with hardware significance is Loop mode. In this 
mode, the Transmitter can forward received data from 
the "preceding" station in a loop of stations to the 
"next" one in the loop. When this station has a frame 
to send, host software can load the start of the frame 
into the TxFIFO and then enable the Transmitter. The 
Transmitter then waits until it detects the transmit- 
permission token called Go Ahead, which is the same 
as the short-Abort sequence 01111111 in HDLC/ 
SDLC mode. The Transmitter then changes this 
character to a Flag and begins transmitting. 


The Mode Registers (CMR, TMR and RMR) 


Three Mode registers control the basic operation and 
serial protocol of the IUSC's Transmitter and Receiver. 


The Channel Mode Register (CMR) selects among the 
various communication protocols mentioned in the 
preceding sections. Figure 35 shows that the MSbyte 
controls the mode of the Transmitter, while the LSbyte 


controls that of the Receiver. Software can select the 
modes of the two modules independently by writing 
bytes to the CMR or, on a 16-bit bus, it can set both 
modes simultaneously using a 16-bit write. 


Within each byte, the four LSbits select the major 
communications protocol. The coding for these fields 
is similar but not identical because some modes apply 
only to the Transmitter while others apply only to the 
Receiver: 


TxMode RxMode 
Value {CMR11-8) {CMR3-0) 
0000 Asynchronous Asynchronous 
0001 - External Sync 
0010 Isochronous Isochronous 
0011 Asyne w/Code V. Async w/Code V. 
0100 Monosync Monosync 
0101 Bisynec Bisync 
0110 HDLC/SDLC HDLC/SDLC 
0111 Transp. Bisync Transp. Bisync 
1000 Nine-Bit Nine-Bit 
1001 802.3 (Ethernet) 802.3 (Ethernet) 
1010 - - 
1011 - - 
1100 Slaved Monosync - 
1101 - - 
1110 HDLC/SDLC Loop - 
1111 - - 


Zilog reserves values shown above as "-" for use in 
future USC family members; they should not be 
programmed in the indicated field. 


Later sections describe each of these modes and 
protocols individually, including the significance of the 
Tx and RxSubMode bits (CMR15-12 and CMR7-4 
respectively) in each case. The various major modes 
use the SubMode bits differently, to control protocol 
variations and options that are specific to each mode. 
(Sometimes the same SubMode option applies to two 
or more related major modes.) 


Understanding the choices offered by the Channel 
Mode Register is perhaps the most important single 
factor in understanding the IUSC. 


The Transmit and Receive Mode Registers (TMR and 
RMR) contain basic control information for the 
Transmitter and Receiver, including the serial format 
and data-integrity checking. Figures 36 and 37 show 
the TMR and RMR respectively. 


15 14 13 12 11 10 9 8 


7 6 5 4 3 2 1 0 


Figure 35. The Channel Mode Register (CMR) 
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TxCRC} TxCRC | TxCRC TxPar 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


Figure 36. The Transmit Mode Register (TMR) 





RxCRC| RxCRC RxPar 
RxCRCType QAbort] RxParType RxLength RxEnable 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


Figure 37. The Receive Mode Register (RMR) 


Enabling and Disabling the Receiver and 
Transmitter 


The TxEnable and RxEnable fields (TMR1-0 and 
RMR1-0) enable and disable the Transmitter and 
Receiver to send and receive serial data. 00 in 
TxEnable disables the Transmitter, so that it keeps its 
output inactive and doesn't transfer characters from 
the TxFIFO to its shift register. Assuming that the 
TxDMode field (lIOCR7-6) is 00 to propagate the 
Transmitter's output onto TxD, the pin shows constant 
Mark/high if the MSBit of the Txidle field (TCSR10) is 
1 and/or the TxEncode field (TMR15-14) is 000 
indicating NRZ data. If TxDMode is 00, TCSR10 is 0, 
and TxEncode is non-zero, the TxD pin shows 
encoded ones. 


lf software changes TxEnable to 00 while the Trans- 
mitter is sending a character, it discards the character 
and disables its output immediately. Similarly, 00 in 
RxEnable disables the Receiver: it ignores the RxD pin 
and doesn't assemble characters. If software changes 
this field to 00 while the Receiver is assembling a 
character, it discards the partial character. 


01 in TxEnable or RxEnable disables the Transmitter 
or Receiver in a more "graceful" way than 00. If soft- 
ware changes TxEnable to 01 while the Transmitter is 
sending asynchronous data, it finishes sending the 
current character before going inactive. If software 
changes TxEnable to 01 while the Transmitter is 
sending synchronous data, it finishes sending the 
current frame or message before going inactive. _ If 
software changes RxEnable to 01 while the Receiver 
is receiving asynchronous data, it finishes assembling 
the current character before going inactive. If software 
changes RxEnable to 01 while the Receiver is 
receiving synchronous data, it finishes receiving the 
current frame or message before going inactive. 


10 in TxEnable or RxEnable enables the Transmitter 
or Receiver unconditionally. 


11 in TxEnable places the Transmitter under the 
control of the /CTS pin. /CTS should be programmed 
as an input in the CTSMode field of the Input/Output 
Control Register (IOCR15-14). In this case, the 
Transmitter only starts sending a character when /CTS 
is low. If /CTS goes high while the Transmitter is 
sending a character in an async mode, it finishes 
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sending the character before going inactive. In any 
synchronous mode, /CTS high summarily disables the 
Transmitter. In either case, sooner or later, /CTS high 
forces TxD to Mark or ones as described above for 
TxEnable=00. 


11 in RxEnable places the Receiver under the control 
of the /DCD pin. /DCD should be programmed as an 
input in the DCDMode field of the Input/Output Control 
Register (IOCR13-12). The Receiver ignores the RxD 
pin and does not assemble characters when /DCD is 
high. If /DCD goes high while the Receiver is as- 
sembling a character in External Sync mode or 802.3 
(Ethernet) mode, it finishes assembling the character 
and places it in the RxFIFO before going inactive. In 
any other mode the Receiver discards any partial 
character when /DCD goes high. 


Character Length 


The TxLength and RxLength fields (TMR4-2 and 
RMR4-2) control how many bits the Transmitter sends 
and the Receiver assembles in each character. The 
IUSC interprets both fields as follows: 


XMR4-2 Character Length 
000 8 bits 
001 1 bie 
010 2 bits 
011 3 bits 
100 4 bits 
101 5 bits 
110 6 bits 
111 7 bits 


When TxLength specifies less than 8 bits, the Trans- 
mitter discards/ignores one or more of the more-signif- 
icant bits of each byte that it takes from the TxFIFO. 


When RxLength specifies less than 8 bits, the Re- 
ceiver replicates the most significant received bit in the 
more significant bits of each byte it places in the 
RxFIFO. For Async mode, it includes a received Par- 
ity bit, if any, in each data byte. If RxLength, plus the 
Parity bit if any, is less than 8 bits, the Receiver fills 
out the more-significant bits of each byte with the Stop 
bit, which is 1 except when there's a Framing Error. 


When RxLength is less than 8 in synchronous modes 
including HDLC/SDLC, the Receiver fills out the more 


significant bits of each byte with the last received bit 
(the parity bit if one is used), except in three cases: 

1. In Monosync and Bisync modes, when CMR4 is 1 
so that sync characters are 8 or 16 bits long, but 
data characters contain less than 8 bits, each data 
character is left-justified in its byte. 

In HDLC/SDLC mode, when CMR85-4 are non-zero 
so that address and control characters are 8 bits 
long but subsequent characters are less than 8 
bits long, each subsequent character is left- 
justified in its byte. 

In HDLC/SDLC mode, if the frame doesn't end on 
a character boundary, its final data bits are left- 
justified within the (right-justified) number of bits 
specified by RxLength, unless case 2 also applies, 
in which case they're left-justified in the last byte. 
(The number of bits in the last character of each 
HDLC/SDLC frame is always indicated in the 
RxResidue field of the RCSR.) 


In any of these three cases of left-justified data, the 
less-significant bits are left over from the previous 
character. 


If software enables parity checking in an asynch- 
ronous mode, the Transmitter and Receiver handle the 
parity bit as an additional bit after the number of bits 
defined by TxLength and RxLength. If software 
selects parity checking in a synchronous mode, the 
Transmitter and Receiver handle the parity bit as the 
last of the number of bits specified by TxLength and 
RxLength. 


In Async with Code Violations (1553B) mode only, the 
Transmitter and Receiver can handle "words" that 
include up to 16 data bits, treating each word as two 
characters in the Transmit and Receive FIFOs. When 
software selects this option, the number of data bits 
per word is eight more than the number usually 
indicated by TxLength and RxLength. 


Software should reprogram RxLength only while the 
Receiver is either disabled, in Hunt state in a 
synchronous mode, or between characters in an 
asynchronous mode. Software can reprogram 
TxLength at any time, but a new length takes effect 
only when the Transmitter loads the next character 
into its shift register. : 


Parity, CRC, Serial Encoding 


A later section of this chapter, Parity Checking, 
discusses how bits 7-5 of the TMR and 8-5 of the 
RMR control parity checking. 


Similarly, the later section Cyclic Redundancy 
Checking describes how bits 12-8 of the TMR and 12- 
9 of the RMR control CRC checking. 


The TxEncode and RxDecode fields (TMR15-13 and 
RMR15-13) specify how the Transmitter encodes 
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serial data on the TxD pin and how the Receiver 
decodes it on the RxD pin. See Chapter 3 for a full 
description of the following encodings: 


XMR15-13 Data Format 
000 NRZ 
001 NRZB 
010 NRZI-Mark 
011 NRZI-Space 
100 Biphase-Mark 
101 Biphase-Space 
110 Biphase-Level 
111 Differential Biphase-Level 


Asynchronous Mode 


Software can select classic asynchronous operation 
for both the Transmitter and the Receiver, by program- 
ming the TxMode and RxMode fields (CMR11-8 and 
CMR3-0 respectively) to 0000. The earlier Figure 32 
shows how a "0" Start bit precedes each character 
and a "Stop bit" follows each, the latter being a "1" 
condition that's more than 1/2 bit time long. The idle 
state of the line is 1, and the Transmitter and Receiver 
divide their input clocks by 16, 32, or 64 to arrive at 
the nominal bit time. 


Software can make the Transmitter calculate and send 
a parity bit with each character and can make the 
Receiver check such parity bits, as described in the 
later section Parity Checking. 


The two more significant TxSubMode bits (CMR15-14) 
control the minimum number of Stop bits that the 
Transmitter sends between consecutive characters. 
The Transmitter interprets them as follows: 


CMR15-14 Minimum Length of Tx Stop 
00 One bit time 
01 Two bit times 
10 One, "Shaved" per CCR11-8 
11 Two, "shaved" per CCR11-8 


When CMRi15 is 1 in this mode, the TxShave field of 
the Channel Control Register (CCR11-8) controls the 
exact length of the minimum Stop bit(s). If the 4-bit 
value in TxShaveL is "n", then the lengih of the shaved 
stop bit is (n+1)/16 bit times. The following table 
summarizes the stop bit possibilities afforded by 
CMR15-14 and CCR11-8: 
CMR15-14 
00 
01 


Minimum Length of Tx Sto 


CCR11-8 


XXXX 1 bit time 


XXXX 2 bit times 





10 0000-0111 1/2 or less: DO NOT USE 
10 1000 9/16 

10 1001 5/8 

10 1010-1110 11/16 to 15/16 

10 1111 1 (as with CMR15-14=00) 


11 0000 17/16 


il 0001 9/8 
nee 0010-1110 19/16 to 31/16 
11 1111 2 (as with CMR15-14=01) 


The two LSbits of the Tx and RxSubMode fields 
(CMR13-12 and 5-4) control the factors by which the 
Transmitter and Receiver divide their TxCLK and 
RxCLK inputs to arrive at the nominal bit length. The 
IUSC interprets both fields as follows: 


CMR13-12 
“MR5-4 Nominal Bit 1 
00 TxClock or RxClock / 16 
01 MTxClock or RxClock / 32 
10 TxClock or RxClock / 64 
11 Reserved, do not program 


For the Receiver, choosing a larger divisor makes it 
sample the data on RxD more often. This may result 
in a slightly better error rate in marginal circum- 
stances. For the Transmitter there is no significance 
to the divisor chosen, other than the convenience of 
choosing the same value as for the Receiver, so that 
the same source can be used for both RxCLK and 
TxCLK. (See Chapter 3 for more information about 
clock selection.) 


Zilog reserves the two MSbits of the RxSubMode field 
(CMR7-6) in Asynchronous mode for use in future 
products. They should always be programmed as 00. 


There is no such thing as a "received stop length" 
parameter: the Receiver does not expect or check for 
a particular stop bit length. It simply samples the 
received data at the nominal midpoint of a single Stop 
bit, and loads a corresponding Framing Error bit into 
the RxFIFO with each character. This bit migrates 
through the FIFO with its associated character and 
eventually appears as the CRCE/FE bit in the Receive 
Command / Status Register (RCSR3). Note that 
RCSR3 can represent the status at the time that a 
character marked with RxBound' status was read from 
the RxFIFO, or the status of the oldest 1 or 2 
characters that are still in the RxFIFO, as described 
later in Status Reporting. 


Break Conditions 


A Break condition is a period of Space (zero) state on 
an Async line, that's longer than the length of a 
character. Such a sequence traditionally signals an 
exceptional condition or a desire to stop transmission 
in the opposite direction. Alternatively, a Break may 
mean that the switched or physical connection with the 
other station is broken. The Receiver detects a Break 
condition when it samples a supposed Stop bit as 
Space/zero (a Framing Error) and all the data bits 
were also Space/zero. In this case the Receiver 


1 Previous USC documentation called RxBound "CV/EOF/EOT". 
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doesn't place the all-zero character in the RxFIFO, but 
instead sets the Break/Abort bit in the Receive 
Command/Status Register (RCSR5). This bit can be 
enabled to cause an interrupt at the start of a Break, 
but there's no provision for an interrupt at the end of a 
Break. Software can tell when the Break ends by 
polling the Break/Abort bit. This is because the bit 
doesn't go back to 0 until software has written a 1 to 
the bit to "unlatch" it, and RxD has gone back to 
1/High/Mark. 


Software can send a Break by programming the 
TxDMode field of the Input/Output Control Register 
(IOCR7-6) to 10 to force TxD to low/space. Then it 
can use whatever kind of timing resources it has 
available to measure the desired duration of the 
Break. After this, it can program TxDMode back to 11 
to force TxD to high/mark or to 00 to resume normal 
operation. Chapter 3 describes the I|USC's Counters 
and Baud Rate Generators that may be useful in 
timing the length of a transmitted Break. While most 
modern serial controllers will detect a Break that's only 
slightly longer than a character, older conventions 
required a Break to be much longer: 200 milliseconds 
or more. 


Isochronous Mode 


Software can select Isochronous operation for the 
Transmitter and the Receiver, by programming the 
TxMode and RxMode fields (CMR11-8 and CMR3-0 
respectively) to 0010. This mode is similar to Asynch- 
ronous mode as described above, except that the 
Transmitter and Receiver use 1X instead of 16X, 32X, 
or 64X clocking. This typically means that an external 
bit clock must be provided. It's possible to use the 
DPLL to recover a 1X clock, but this is a lot like what 
the Receiver does in Async mode anyway. 


Of the options available in the Channel Mode Register 
for Async mode, the only one that applies in Iso- 
chronous mode is CMR14. This controls whether the 
Transmitter sends one or two stop bits: 
CMR14 Length of Tx Stop 
0 1 bit time 
1 2 bit times 


The IUSC doesn't use the other 3 bits of the 
TxSubMode field in Isochronous mode, nor any of the 
RxSubMode bits, but Zilog reserves these bits for 
functional extensions in future products. Software 
should always program them with zeroes in Isochron- 
ous mode on an IUSC. 


Nine-Bit Mode 


This mode is compatible with various equipment 
including some Intel single-chip microcontrollers. In 
some contexts it's called "address wake-u mode". 
Software can select it for the Transmitter and the 
Receiver by programming the TxMode and RxMode 
fields (CMR11-8 and CMR3-0 respectively) to 1000. 
Operation on the line is similar to Async mode, using a 
single stop bit and either eight data bits or seven data 
bits plus a parity bit. Following the eighth (MS) data 
bit or the Parity bit, an additional bit differentiates 
normal data characters from "destination address" 
characters. Address characters identify which of 
several stations on the link should receive the fol- 
lowing data characters. In effect, Nine Bit mode is like 
a Local Area Network using asynchronous hardware. 


The Transmitter saves TxSubMode bit 3 (CMR15) with 
each character as it goes into the TxFIFO, and sends 
it as that character's address/data bit. By convention 
a 0 signifies "data" and a 1 signifies "address". As 
software or the Transmit DMA channel writes each 
character into the TxFIFO, the IUSC saves the state 
of CMR15 with it. This bit accompanies the character 
through the FIFO and out onto the link. 


TxSubMode bit 2 (CMR14) selects between eight data 
bits or seven data bits plus parity: 


ne ee 
Eight 


: Seven plus parity. The 
TxParEnab bit in the Transmit 
Mode Register (TMR5) must be l. 
Typically, Nine Bit receivers check the parity of 


received address bytes. This means that when 
software selects eight data bits, it must calculate its 
own parity bit in the MSBit of addresses. 


As in Async mode, the two LSbits of the Tx and 
RxSubMode fields (CMR13-12 and 5-4) control 
whether the Transmitter and Receiver divide their 
TXCLK and RxCLK inputs by 16X, 32X, or 64X to 
arrive at the nominal bit length. See the preceding 
Async section for the field encodings and a discussion 
of the significance of this choice. 


The Receiver sets the RxBound status bit for a 
received address character, that is, a character that 
has its ninth bit equal to 1. This bit accompanies the 
character through the RxFIFO and ends up in the 
Receive Command / Status Register (RCSR4). Note 
that this mode uses the RxBound indicator quite a bit 
differently from other modes, in that it marks the start 
of each received block rather than the end. Because 
of this, some of the mechanisms associated with 
RxBound, that are described in later sections, aren't of 
much use in Nine-Bit mode. For example, you 
probably wouldn't want to store a Receive Status 
Block for an address character... 
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The IUSC doesn't use the two MSBits of the 
RxSubMode field (CMR7-6) in Nine Bit mode, but 
Zilog reserves these bits for future enhancements and 
software should program them as 00 in this mode. 


Async with Code Violations (1553B) Mode 


Software can select the Async with Code Violations 
(ACV) mode for the Transmitter and the Receiver by 
writing 0011 to the TxMode and RxMode fields, 
CMR11-8 and CMR3-0. The main use of this mode is 
to implement MIL-STD-1553B communications. 
However, there are at least two variations of this 
protocol in use, and the mode has some interesting 
properties for use in proprietary datacom schemes as 
well. Therefore this section will discuss the mode “at 
arm's length from" 15538 itself. 


The mode resembles the Isochronous mode in that the 
Transmitter and Receiver use a 1X clock instead of 
16, 32, or 64X oversampling. 


1553B defines the smallest indivisible group of data on 
the line as either 16 or 14 consecutive bits, and calls 
such a group a "word". This section will use this term 
in this way as well as to describe 16 bits transferred to 
or from a FIFO. Weill call 8 bits transferred to or from 
a FIFO a "byte". 


Zilog recommends ACV mode only with Biphase- 
encoded data. Standard 1553B uses Biphase-Level 
encoding while an Army variant uses Biphase-Mark. 
(Before reading further you may want to review the 
Data Formats and Encoding section of Chapter 3.) 


ACV mode replaces the Start bit of Async and 
Isochronous modes by a unique 3-bit sequence, of 
which the first and third do not include the usual clock 
transition. There are two different sequences: two 
ones followed by a zero begin a "command/status 
word" while two zeroes followed by a one signify a 
"data word". 


Because of the missing clock transitions, these 
sequences can't occur in the subsequent data bits for 
each character. This allows a Receiver to recognize 
word boundaries even in a continuous data stream. 
(This can be difficult in normal async applications.) 


The idle line state between characters is all ones as in 
other async modes. Because the 3-bit Start sequen- 
ces are unique and recognizable, there's no need for a 
Stop bit to ensure a transition between characters. 
Therefore Stop bits are optional in ACV mode. 


In standard 1553B, 16 data bits follow each Start 
sequence and are followed by an even parity bit. In an 
Army variant there are 14 data bits per word and no 
parity bit. Figure 38 shows these two standard data 
formats, and includes both kinds of Start sequences 
for all four Biphase modes. 


3-bit “Command/ 
Status" Start 


Standard 
1553B: 


* 
‘ 


Army 


14 Data Bit 
Variant: asses 


<> 
: 3-bit “Command/ : 
Status" Start : 


"Command/Status" Start Sequence 
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Data 
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Bits: 
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clock : 


_ Figure 38. A 1553B Command/Status Word Followed by a Data Word 


If software selects ACV mode with any of the four 
NRZ encodings, the IUSC sends and scans for Start 
sequences that contain the same data bits, but such 
Start sequences aren't uniquely recognizable as in 
Biphase modes. 


The two MSBits of the TxSubMode field (CMR15-14) 
select the minimum number of Stop bits that the 
Transmitter sends between words: 


CMR15-14 # of Stop Bits Transmitted 
00 One 
01 Two 
10 None 
11 Reserved; do not program 


If the CMR13 bit of the TxSubMode field is 1 in ACV 
mode, the Transmitter sends 8 more data bits per 
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character/word than the number specified by the 
TxLength and TxParEnab fields of the Transmit Mode 
Register (TMR4-2 and TMR85). If CMR13 is 0, the 
Transmitter sends 8 or less bits in each character, as 
in other modes. 


Similarly, if CMR4 in the RxSubMode field is 1 in ACV 
mode, the Receiver expects 8 more data bits per 
character/word than the number specified by the 
RxLength and RxParEnab fields of the Receive Mode 
Register (RMR4-2 and RMRS), and it marks the sec- 
ond byte of each received word with RxBound status 
in the RxFIFO. If CMR4 is 0, the Receiver expects 8 
or less bits per character as in other modes, and it 
marks every received character with RxBound status. 


Thus, for standard 1553B communications, program 
both CMR13 and CMR4 to 1, and program TMR7-2 


and RMR7-2 to 001000 to specify 16 total data bits fol- 
lowed by an even parity bit. For the Army variant, 
again program CMR13 and CMR4 to 1, but program 
TMR7-2 and RMR7-2 to 000110 for 14 data bits with- 
out a parity bit. 


When CMR13 and CMR4 are 1, each word on the line 
corresponds to either one 16-bit transfer, or two 8-bit 
transfers, to and from the FIFO's. Software can use 
the commands available in the Channel Command / 
Address Register (CCAR) to match the bit ordering 
used on the serial link and the byte ordering employed 
by the host processor. 


The CMR12 bit of the TxSubMode field controls which 
of the two Start sequences the Transmitter sends in 
front of each word. When CMR172 is 1, it sends two 
ones followed by a zero, which signifies a "command/ 
status word". When CMR712 is 0, it sends two zeroes 
followed by a one, signifying a "data word". Software 
has to toggle CMR12 to send the two kinds of words. 
The !USC captures the state of CMR12 in the TxFIFO 
with each data word, so that software can change it as 
needed. 


The Receiver sends the identity of the Start sequence 
for each word through the RxFIFO with the data. At 
the "host end" of the FIFO, this information is available 
as the ShortF/CVType bit in the Receive 
Command/Status Register (RCSR8). ShortF/CVType 
is 1 for a "command/status" word and O for a "data" 
word. Note that RCSR8 can represent the status at 
the time that an RxBound character was read from the 
RxFIFO, or the status of the oldest 1 or 2 characters 
that are still in the RxFIFO, as described later in 
Status Reporting. 


Using "programmed I/O", software has to set CMR12 
and sample RCSR8 for the two kinds of Start 
sequences. These matters can be handled on a DMA 
basis, without processor intervention for each word. 
Transmit software can use the Transmit Control 
Block? feature to change CMR12 for each block of 
words that use the same Start sequence. Receiving 
software can use the Receive Status Block feature to 
make the IUSC store the contents of the RCSR in 
memory after each word received. This status 
includes the ShortF/CVType bit. See Using TCB's and 
RSB's in ACV (1553B) Mode later in this chapter for 
more details on how to use these features. 


The IUSC doesn't use the three MSBits of the 
RxSubMode field (CMR7-5) in ACV mode, but Zilog 
reserves these bits for future enhancements and soft- 
ware should always program them as 000 in this 
mode. 


2 Previous USC documentation called this the Transmit Status Block feature. 
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External Sync Mode 


Software can select this mode only for the Receiver, 
by programming the RxMode field of the Channel 
Mode Register (CMR3-0) as 0001. This value is not 
defined for the TxMode field (CMR11-8). 


This is the most primitive synchronous mode. To use 
it, software must program the DCDMode field of the 
Input/Output Control Register (IOCR13-12) to 01, to 
specify that the /DCD pin carries a Sync input. 
External hardware must provide a low-active signal on 
this pin, that controls when the Receiver should 
capture data. When the external hardware establishes 
synchronization and/or data validity, it should drive 
/DCD low. The timing should be such that the lIUSC 
first samples /DCD low at the same rising edge of 
RxCLK at which the first data bit that it should capture 
is available on RxD. (Typically RxCLK comes directly 
from the /RxC pin in this mode.) 


While /DCD stays low the Receiver samples RxD on 
each rising edge of RxCLK. Ideally, the external hard- 
ware should negate /DCD such that the IUSC samples 
it high on the rising RxCLK edge after the one on 
which it samples the last bit of the last character. But 
if /DCD goes high while the Receiver is in the midst of 
assembling a received character, it continues on to 
sample the remaining bits of the character and place 
the character in the RxFIFO. Because of this, it's OK 
for /DCD to go high during the last character, at any 
time after a hold time after the RxCLK edge at which 
the Receiver samples the first bit of the character. 


Software can make the Receiver check a parity bit in 
each character as described in the following section 
Parity Checking. Besides or instead of character 
parity, software can make the Receiver check a CRC 
code as described in the Cyclic Redundancy Checking 
section. 


The IUSC doesn't use the RxSubMode field (CMR7-4) 
in External Sync mode, but Zilog reserves this field for 
future enhancements and software should program it 
as 0000 in this mode. 


Monosync and Bisync Modes 


The Binary Synchronous Communications protocol put 
forth by the IBM Corporation in the 1960's is often 
abbreviated as "Bisync". But we will use the latter 
term more generally, to mean an IUSC mode in which 
the Transmitter sends, and the Receiver searches or 
"hunts" for, a Syne pattern composed of two charac- 
ters totalling 16 bits or less. By contrast, we'll use the 
term "Monosync" to mean a mode in which the 
Transmitter sends, and the Receiver matches, a sync 
pattern of eight bits or less. Use of Bisync mode with 
the two sync characters equal represents a middle 
ground, having the advantage that the two-character 


pattern match by the Receiver is more reliable and 
secure than the sync match in Monosync mode. 


Software can select these modes for the Transmitter 
and/or the Receiver, by programming the value 0100 
(for Monosync) or 0101 (for Bisync) into the TxMode 
and/or RxMode fields of the Channel Mode Register 
(CMR11-8 and CMRS8-0). 


Software can make the Transmitter calculate and send 
a parity bit with each character and can make the 
Receiver check such parity bits, as described in the 
Parity Checking section. 


In such character-oriented synchronous modes, blocks 
of consecutive characters are called messages. 
Besides or instead of character parity, software can 
make the Transmitter calculate and send a Cyclic 
Redundancy Check (CRC) code for each message 
and can make the Receiver check a CRC in each 
message, as described later in Cyclic Redundancy 
Checking. 


On the transmit side, the Transmitter "concludes a 
message" in either of two situations: when the 
Transmitter underruns or after it sends a character 
marked with "EOF/EOM" status. The Transmitter 
underruns when the TxFIFO is empty and the transmit 
shift register needs a new character. Software can 
mark a character as End Of Message directly, using a 
command in the Transmit Command/Status Register 
(TCSR), or more automatically by using the Transmit 
Character Counter as described in a later section. 


The MSBit of the TxSubMode field (CMR15) deter- 
mines whether the Transmitter sends a CRC when it 
concludes a message because of an Underrun 
condition. The TxCRCatEnd bit in the Transmit Mode 
Register (TMR8) determines whether it does so when 
it concludes a message because of a character 
marked as End Of Message. If CMR15 or TMR8 (as 
applicable) is 1, the Transmitter sends the CRC code 
that it has accumulated while sending the message. If 
CMR15 or TMR8 is 0, it doesn't send a CRC code; if 
there's any message-level checking, it must be sent 
like normal data. 


After the CRC, or immediately if CMR15 or TMR8 is 0, 
in Monosyne mode the Transmitter sends the Sync 
character in the LSByte of the Transmit Sync Register 
(TSR7-0). In Bisync mode it sends the "SYN1" 
character in TSR15-8 if CMR14 is 0, while if CMR14 is 
1 it sends one or more character pairs. The Trans- 
mitter takes the first character of each such pair from 
TSR7-0; by convention it's called "SYNO". The second 
character of each pair comes from TSR15-8 and is 
called "SYN1". 


After sending this closing Sync character or pair, 
if/while software doesn't present another message, the 
Transmitter maintains the TxD signal in the “idle line 
state" defined by the Txidle field of the Transmit 
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Command / Status Register (TCSR10-8). If this field 
is 000, it continues to send more of the same Sync 
character or pair that it sent to terminate the message. 
Other TxIdle values select constant or alternating-bit 
patterns, as described later in Between Frames, 
Messages, or Characters.. 


If the CMR13 bit in the TxSubMode field is 1, the 
Transmitter sends a "Preamble" before the "opening" 
sync character that precedes each message. Soft- 
ware can select the length and content of the 
Preamble in the Channel Control Register (CCR11-8). 
A typical use of the Preamble is to send a square- 
wave pattern for bit rate determination by a phase 
locked loop. 


The Transmitter always sends at least one "opening" 
Sync pattern before the first data character of a 
message (after the Preamble if any). In Monosync 
mode it sends one character from TSR15-8, while in 
Bisync mode it sends the "SYNO" character from 
TSR7-0 followed by "SYN1" from TSR15-8. (In Bisyne 
mode an opening Sync sequence is always a char- 
acter pair, regardless of CMR14.) 


The LSBits of the TxSubMode and RxSubMode fields 
(CMR12 and CMRé4 respectively) specify the length of 
the Sync characters that the Transmitter sends before 
and after each message and between messages, and 
for which the Receiver hunts. If CMR12 or CMR¢4 is 1, 
sync characters have the same length as data 
characters, namely the length specified by the 
TxLength field in the Transmit Mode Register (TMR4- 
2) or the RxLength field of the Receive Mode Register 
(RMR4-2). If syne characters are less than 8 bits long, 
they must be programmed in the least significant bits 
of TSR15-8, RSR7-0 and, for Bisync, TSR7-0 and 
RSR15-8. Furthermore, to guarantee that the 
Receiver matches such Sync characters, the "unused" 
MSBits among RSR7-0 (and for Bisync RSR15-8) 
must be programmed equal to the MS active bit. 


If CMR12 or CMR4 is 0, Sync characters are 8 bits 
long regardless of the length of data characters. 


On the receive side, the CMR8S bit of the RxSubMode 
field determines what the Receiver does with Sync 
characters. In CMR85 is 1, the Receiver strips char- 
acters that match the character in RSR15-8, and 
neither places them in the RxFIFO nor includes them 
in its CRC calculation. (In Bisync mode, aside from 
the initial sync match the Receiver treats characters 
that match "SYNO" in RSR7-0, but don't match "SYN1" 
in RSR15-8, as normal data.) If CMRS5 is 0, the 
Receiver places all Sync characters inside a message 
in the RxFIFO and includes them in the CRC 
calculation. 


The IUSC doesn't use the two MSBits of the 
RxSubMode field (CMR7-5) in Monosyne and Bisync 
modes, nor CMR14 in the TxSubMode field in Mono- 


sync mode. Zilog reserves these bits for future 
enhancements, and software should always program 
these bits with zeroes in these modes. 


Transparent Bisyne Mode 


This mode is more specific to the Transparent Mode 
option of IBM Corp.'s Binary Synchronous Communi- 
cations protocol than is the Bisync mode described 
above. Software can select this mode for the Trans- 
mitter and the Receiver, by programming the TxMode 
and RxMode fields of the Channel Mode Register 
(CMR11-8 and CMR3-0) to 0111. 


In Monosyne and Bisync modes the Sync characters 
are programmable, but in this mode the IUSC uses the 
fixed characters "DLE" for the first of a sync pair, and 
"SYN" for the second of a pair. (Software can make 
the Transmitter send only SYNs for closing and idle 
Syncs.) The LSBits of the TxSubMode and 
RxSubMode fields (CMR12 and CMR4) control 
whether the Transmitter and Receiver use the ASCII 
or EBCDIC codes for control characters, with a 1 
specifying EBCDIC. 


Besides using DLE before an opening and possibly a 
closing SYN, the Transmitter can check whether each 
data character coming out of the TxFIFO is a DLE and 
insert another DLE if so. This feature allows any kind 
of data to be sent "transparently". The Transmitter 
doesn't include such an inserted DLE in its CRC cal- 
culation. Software can selectively enable and disable 
this function using the Enable DLE Insertion and 
Disable DLE Insertion commands, as described later 
in the Commands section. In general software should 
enable DLE insertion for sending data and disable it 
for sending a control sequence that starts with DLE. 
The IUSC routes the state controlled by these 
commands through the TxFIFO with each character, 
so that software can change the state as needed. 


Similarly, in Transparent Bisync mode the Receiver 
checks whether each character coming out of its shift 
register is a DLE. If so, it sets a state bit. If the next 
character is also a DLE, the Receiver doesn't include it 
in the RxFIFO nor in the CRC calculation. 


If the character after a DLE is any of the terminating 
codes "ITB", "ETX", "ETB", "EOT", or "ENQ", the 
Receiver places the terminating character in the 
RxFIFO marked with RxBound status. As described in 
later sections, this marking may set the Received Data 
Interrupt Pending bit and thus force an_ interrupt 
request on its /INT pin, and/or it may force a DMA 
request on the /RxREQ pin. 


The first "DLE-SOH" or "DLE-STX" in a message 
makes the Receiver enable its CRC generator for 
subsequent data. Therefore, the CRC in Transparent 
Bisyne mode covers all the data after the first DLE- 
SOH or DLE-STX. 
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The Receiver doesn't take any other special action 
based on received DLE's. 


A Transmitter in Transparent Bisync mode sends a 
DLE-SYN pair at the start of a message, but a 
Receiver in this mode syncs up to SYN-SYN. This is 
so that software can determine "transparency" sepa- 
rately for each message, by testing whether the first 
character of the message in the RxFIFO is a DLE. 


The following table shows the ASCII and EBCDIC 
codes that a IUSC recognizes in this mode: 


ASCII ey EBCDIC © Sate 





Given the dedicated nature of the Sync characters, the 
Transmitter interprets the three MSBits of the 
TxSubMode field similarly to the way it does so in 
Bisyne mode. If CMR15 is 1, it sends a CRC when a 
Tx Underrun condition occurs. If CMR14 is 1, the 
Transmitter sends one or more DLE-SYN pairs after a 
message, else it just sends SYNs. If CMR13 is 1, it 
sends a Preamble sequence before the opening Sync 
at the start of each message. 


The same data checking options apply to this mode as 
in Monosync and Bisync, but since we're quite proto- 
col-specific here, we can say that character parity is 
typically not used while CRC-16 checking is. While 
the Receiver can detect the end of the frame in 
Transparent Bisync mode, the Receive Status Block 
feature can't be used to capture the CRC Error status 
of the frame, for reasons discussed later in the Cyclic 
Redundancy Checking section. But the selective 
inclusion/exclusion of received data in the CRC 
calculation, that's typical of this mode, precludes the 
kind of automatic reception that the RSB feature 
allows in modes like HDLC/SDLC anyway. 


The IUSC doesn't use the three MSBits of the 
RxSubMode field (CMR7-5) in Transparent Bisyne 
mode, but Zilog reserves these bits for future 
enhancements and software should always program 
them as 000 in this mode. 


Slaved Monosync Mode 


This mode applies only to the Transmitter. Software 
selects it by programming 1100 in the TxMode field of 
the Channel Mode Register (CMR11-8), while pro- 
gramming 0100 in the RxMode field (CMRS-0) to 
select Monosync mode for the Receiver. 


The mode is intended to implement the X.21 standard 
and similar schemes in which character boundaries on 
TxD must align with those on RxD. For this to be 
meaningful, RxCLK and TxCLK typically come from 
the same source, as described in Chapter 3. 


Most of the setup and operation in this mode is the 
same as in Monosync mode, which was described in 
an earlier section. CMR15 determines whether the 
Transmitter sends a CRC in an Underrun condition. 
CMR12 selects whether sync characters are the same 
length as data characters, or are 8 bits long. 


CMR13 controls the major operating option in Slaved 
Monosync mode. (In regular Monosync mode this bit 
controls whether the Transmitter sends a Preamble 
before each message; in this mode it can't send one.) 


The Transmitter will not go from an inactive to an 
active state while CMR13 is 0. If CMR13 is 1 when 
the Receiver signals that it has matched a Sync 
character, the Transmitter sets the OnLoop bit in the 
Channel Command / Status Register (CCSR7) and 
becomes active. That is to say, the Transmitter can 
go active at any received Sync character, not just one 
that makes the Receiver exit from "Hunt mode". 


Once the Transmitter starts, operation is identical with 
Monosync mode. The Transmitter sends the Sync 
character from TSR7-0. Then it sends data from the 
TxFIFO, until the TxFIFO underruns or until it sends a 
character marked as End of Message. Then the 
Transmitter sends the CRC if software has pro- 
grammed that it should do so for this kind of termi- 
nation. Finally it sends a Sync character and checks 
the CMR13 bit again. . 


If CMR13 is still 1, the Transmitter waits, sending the 
programmed Idle line condition, until the software 
triggers it to send another message. If, however, soft- 
ware cleared CMR13 to 0 during the message just 
concluded, or if it does so while the IUSC is sending 
the Idle condition, the Transmitter goes inactive but it 
leaves OnLoop (CCSR7) set. In the inactive state it 
sends continuous ones until software programs 
CMR13 back to 1 again, and the Receiver signals 
Sync detection. 


If all the transmitted and received sync and data 
characters are the same length, and the same clock is 
used for both the Transmitter and Receiver, this 
method of starting transmission assures that trans- 
mitted characters start and end simultaneously with 
received characters, as required by X.21. 
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The IUSC doesn't use CMR14 in the TxSubMode field 
in Slaved Monosync mode, but Zilog reserves this bit 
for future enhancements and software should always 
program it as zero in this mode. 


IEEE 802.3 (Ethernet) Mode 


Software can select this mode for the Transmitter and 
the Receiver, by programming 1001 into the TxMode 
and RxMode fields of the Channel Mode Register 
(CMR11-8 and CMR3-0). 


The IUSC's capabilities for handling Ethernet com- 
munications are less comprehensive than those 
offered by various dedicated Ethernet controllers. In 
particular, external hardware must detect collisions 
and generate the pseudo-random "backoff" timing 
when a collision occurs. 


In Ethernet parlance, blocks of consecutive characters 
are called frames rather than messages. 


Since Ethernet is a relatively specific, well-defined 
protocol we can define the proper settings for many of 
the IUSC's register fields and options. We can specify 
the exact values that software should program into the 
Transmit Mode Register (D703,.) and Receive Mode 
Register (D603,,.). These values specify Biphase- 
Level encoding, a 32-bit CRC sent at End of Frame, 
no parity, and 8 bit characters, all according to 
Ethernet practise and IEEE 802.3. In addition the 2 
LSBits specify auto-enabling based on signals from 
external hardware on /CTS and /DCD. 


On the transmit side, software should program the 
TxPreL and TxPrePat fields of the Channel Control 
Register (CCR11-8) to 1110. This value makes the 
Transmitter send the 64-bit Preamble pattern 1010... 
before each frame. In 802.3 mode the Transmitter 
automatically changes the 64th bit from O to 1 to act 
as the "start bit". 


Furthermore, software should program the Txldle field 
of the Transmit Command / Status Register (TCSR10- 
8) to 110 or 111. These values select an Idle line 
condition of constant Space or Mark. This condition, 
in turn, allows external logic to detect the missing 
clock transition in the first bit after the end of the CRC, 
and turn off its transmit line driver. (In a low-cost 
variant, such an Idle state can simply disable an open- 
collector or similar unipolar driver.) Another alternative 
is to use the Tx Complete output on /TxC or PORT7 to 
control the driver. 


External logic must detect collisions that may occur 
while the IUSC is sending, and signal the Transmitter 
by driving the /CTS pin high when this occurs. 
Besides the auto-enable already noted for TMR1-0, 
software should write the CTSMode field of the Input / 
Output Control Register (IOCR15-14) as Ox to support 
this use of /CTS. 
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Figure 39. Carrier Detection for a Received Ethernet Frame 


As in other synchronous modes, the MSBit of the (RSR). It compares RSRO to the first bit received, and 
TxSubMode field (CMR15) controls whether the §RSR15 to the last bit, regardless of any "Select Serial 
Transmitter sends its accumulated CRC code if a Data MSB First" commands that the software may 
Transmit Underrun condition occurs. have written to the RTCmd field (CCAR15-11). The 
Receiver ignores the frame unless the address 
matches, or unless the first 16 bits are all ones, which 
indicates a frame that should be received by all 
stations. The Receiver places the address in the 
RxFIFO so that the software can differentiate "locally 
addressed" frames from "global" ones. 


On the receive side, external logic should monitor the 
link and drive the /DCD pin low when it detects carrier. 
Figure 39 shows the relationship between an Ethernet 
frame on RxD and the signal on /DCD. Besides the 
auto-enable already noted for RMR1-0, software 
should program the DCDMode field of the Input / 
Output Control Register (IOCR13-12) as 01 to control Except in the CRC, characters ("octets") are sent 
the /DCD pin. LSBit first. The Length field that follows the Desti- 
nation and Source Address fields is sent MSByte-first. 
IEEE 802.3 doesn't include any other byte ordering 
information. 


After /DCD goes low, the Receiver hardware hunts for 
58 alternating bits of preamble, with the final 0 
changed to a 1 as a "start bit". When it finds this 
sequence it starts assembling data and may check the The IUSC doesn't use the three LSBits of the 
Destination Address in the frame as described below. TxSubMode field (CMR14-12) in 802.3 mode, nor the 
three MSBits of RxSubMode (CMR7-5), but Zilog re- 


After a frame, the external hardware should drive serves these bits for future enhancements. Software 


/DCD high so that it sets up to the rising RxCLK edge ' ae 
after the one at which it samples the last bit of the should always program them with zeroes in this mode. 
CRC. In this mode and External Sync mode only 

among synchronous modes, if /DCD goes high while HDLC / SDLC Mode 

the Receiver is in the midst of assembling a character, | Software can select this mode for both the Transmitter 
it continues on to sample the remaining bits of the and the Receiver, by writing 0110 to the TxMode and 
character and place the character in the RxFIFO. RxMode fields of the Channel Mode Register (CMR11- 


The receiver marks the character that was partially or penne) 

completely assembled when /DCD went high with In some sense this is the most important mode of the 
RxBound status in the RxFIFO. As described in later IUSC, at least for new designs. It is similar to char- 
sections, this marking may set the Received Data acter-oriented synchronous modes in that data char- 
Interrupt Pending bit and thus force an interrupt acters follow one another on the serial medium without 
request on its /INT pin, and/or it may force a DMA any extra/overhead bits, and are organized into blocks 
request on the /RxREQ pin. of data with CRC checking applied to the block as a 


The LSBit of the RxSubMode field (CMR4) controls wee: 

whether the Receiver checks an Address field at the | For HDLC and SDLC, the blocks of data are called 
start of each frame. If CMR4 is 0, the Receiver places = frames. Uniquely recognizable 8-bit sequences called 
all received frames in the RxFIFO and leaves address- Flags, consisting of 01111110, precede and follow 
checking to the software. (Some contexts call this each frame. HDLC/SDLC protocols ensure the 
"oromiscuous mode".) If CMR4 is 1, the Receiver uniqueness of Flags, without imposing any restrictions 
compares the first two characters (16 bits) of each on the data that can be transmitted, by having the 
frame to the contents of the Receive Sync Register Transmitter insert an extra 0 bit whenever the last six 
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bits it has sent are 011111. A Receiver, in turn, 
removes such an inserted zero bit whenever it has 
sampled 0111110 in the last seven bit times. 


Besides Flags, HDLC and SDLC define another 
uniquely recognizable bit sequence called an Abort, 
consisting of a zero followed by more consecutive 
ones than the six in a Flag. Depending on the exact 
dialect of HDLC or SDLC, and the security desired in 
communicating an abort, software can program the 
Transmitter to send Aborts consisting of a zero 
followed by either 7 or 15 consecutive ones. 


On the Transmit side, the two MSBits of the 
TxSubMode field (CMR15-14) control what the Trans- 
mitter does if a Transmit Underrun condition occurs, 
that is, if it needs another character to send but the 
TXFIFO is empty: 

CMR15-14 Underrun Response 


00 Send an Abort consisting of 
01111111 

01 Send an Abort consisting of a 
zero followed by 15 
consecutive ones 

10 Send a Flag 

11 Send the accumulated CRC 


followed by a Flag, that is, 
make the data transmitted so 
far into a proper frame. 


After sending the sequence specified by this field, the 
Transmitter sends the next frame if software or the 
Transmit DMA channel has placed new data in the 
TXFIFO. Otherwise it sends the Idle line condition 
specified by the Txldle field of the Transmit Command 
/ Status Register (TCSR10-8), as described later in 
Between Messages, Frames, or Characters. That 
section also describes the conditions under which the 
Transmitter will combine the closing Flag of one frame, 
and the opening Flag of the next, into a single 8-bit 
instance. Furthermore, the same section describes 
the feature of a 16C32 whereby software can ensure 
that a programmable minimum number of Flags is sent 
between frames. 


Software can make the Transmitter send an Abort 
sequence at any time, by writing the "Send Abort" 
command to the TCmd field of the Transmit Com- 
mand/Status Register (TCSR15-12). If CMR15-14 is 
01 as described above, the Transmitter sends an 
extended Abort when software issues this command; 
otherwise it sends the shorter Abort sequence. 


lf CMR13 is 1, the Transmitter sends the Preamble 
sequence defined by the TxPreL and TxPrePat fields 
of the Channel Control Register (CCR11-8), before it 
sends the opening Flag of each frame. 


If the Txidle field (TCSR10-8) is 000 to select Flags as 
the idle line condition, CMR12 selects whether con- 
secutive idle Flags share a single intervening 0. If 
CMR12 is 1, the idle pattern is 011111101111110..., 
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while if CMR12 is 0 it is 01111110 01111110... A Flag 
that opens or closes a frame never shares a zero with 
an idle-line Flag, even if CMR12 is 1. 


On the Receive side, when the receiver detects the 
closing Flag of a frame it marks the preceding (partial 
or complete) character with RxBound status in the 
RxFIFO. As described in later sections, this marking 
may set the Received Data Interrupt Pending bit and 
thus force an interrupt request on its /INT pin, and/or it 
may force a DMA request on the /RxREQ pin. 


The receiver automatically copes with single Flags 
between frames, and with shared zeroes between 
Flags, as described above for the transmit side. 


Recelved Address and Control Field Handling 


The RxSubMode field in the Channel Mode Register 
(CMR7-4) determines how the Receiver processes the 
start of each frame, i.e., whether it does anything 
special for Address and/or Control fields. To the 
extent that the Receiver handles Address or Control 
field(s), it does so in multiples of 8 bits. Thereafter it 
divides data into characters of the length specified by 
the RxLength field of the Receive Mode Register 
(RMR4-2). The Receiver interprets this field as 
described below. (An "x" in a bit position means the 
bit doesn't matter.) 


CMR7-4 Address/Control Processing 
xx00 The Receiver doesn't handle an 
Address or Control field. It 
simply divides all the data in 
received frames into characters 
per RxLength and places them in 
the RxFIFO. 


The Receiver checks the first 8 
bits of each frame as an address. 
If they are all ones or if they 
match the contents of the LSByte 
of the Receive Sync Register 
(RSR7-0), the Receiver receives 
the frame into the RxFIFO, other- 
wise it ignores the frame through 
the next Flag. After placing the 
first 16 bits of the frame in the 
FIFO as two 8-bit bytes, it 
divides the rest of the frame 
into characters per RxLength. 


xx01 


The Receiver checks an 8-—bit 
address as described above. 
these bits are all ones or if 
they match the RSR, the Receiver 
places the first 24 bits of the 
frame in the RxFIFO as 3 8-bit 
bytes before shifting to dividing 
characters according to RxLength. 


x010 
If 


The Receiver checks an 8-bit 
address as described above. 
these bits are all ones or if 
they match the RSR, the Receiver 
places the first 32 bits of the 


x110 
If 


frame in the RxFIFO as 4 8-bit 
bytes before shifting to dividing 
characters according to RxLength. 


0011 The Receiver processes an Ex- 
tended Address at the start of 
each frame. First it checks the 
first 8 bits of the frame as 
described above. If these bits 
are all ones or if they match the 
RSR, as the Receiver places each 
8 bits of the address into the 
RxFIFO, it checks the LSBit of 
the 8. If the LSBit is 0, it 
goes on to put the next 8 bits 
into the RxFIFO as part of the 
address as well, through an 
address byte that has its LSBit 
1. Then, the Receiver places the 
next 16 bits of the frame into 
the RxFIFO as two 8-bit bytes, 
before shifting to dividing. char- 
acters according to RxLength. 


0111 The Receiver processes an Ex- 
tended Address as described for 
0011. If the first 8 bits of the 
address are all ones or if they 
match the RSR, the Receiver 
places the 24 bits after the ex- 
tended address into the RxFIFO as 
3 8-bit bytes, before shifting to 
dividing characters per RxLength. 


1011 The Receiver processes an Ex- 
tended Address as described for 
0011, and then an "Extended Con- 
trol field". If the first 8 bits 
of the address are all ones or if 
they match the RSR, the Receiver 
places the next 8 bits after the 
extended address in the RxFIFO 
without examination. Then, as it 
stores each subsequent 8 bits in 
the RxFIFO, the Receiver checks 
the MSBit of the 8. If the MSBit 
is 1, it continues to receive 
more 8=bit bytes, through one 
that has its MSBit 0. Thereafter 
the Receiver places one more 8- 
bit byte into the RxFIFO, before 
shifting to dividing characters 
per RxLength. 


This mode differs from that 
described above for 1011 only in 
that the Receiver places the 16 
bits after the extended address 
in the RxFIFO without exami- 
nation, before starting to check 
MSBits for the end of the 
“extended Control field". 


1111 


Note that even though the Receiver can scan through 
an Extended Address, it will still only match its first 
byte. Note also that it matches RSRO against the first 
bit received, and RSR7 against the last bit, regardless 
of whether software has written a "Select Serial Data 
MSB First" command to RTCmd (CCAR15-11). 
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If the RxSubMode field specifies some degree of 
Address and Control checking, that is, if it's not xx00, 
and a frame ends before the end of the Address and 
possibly the Control field specified by the RxSubMode 
value, the Receiver sets a Short Frame bit in the 
status for the last character of the frame. This bit 
migrates through the RxFIFO with the last character, 
eventually appearing as the ShortF/CVType bit in the 
Receive Command / Status register (RCSR8). Note 
that this bit can represent the status at the time that an 
RxBound character was read from the RxFIFO, or the 
status of the oldest 1 or 2 characters that are still in 
the RxFIFO, as described in a later section, Status 
Reporting. Note, however, that this length checking 
doesn't report a problem if a frame ends within a CRC 
that follows an address and control field. 


If RxLength (RMR4-2) is 000, specifying 8 bits per 
character, all RxSubMode (CMR7-4) values except 
xx00 are equivalent aside from short-frame checking. 


Frame Length Residuals 


The Receiver detects and strips inserted zeroes, 
Flags, and Aborts before any other processing, and 
doesn't include these bits/sequences in the RxFIFO 
nor in CRC calculations. If the Receiver has assem- 
bled a partial character when it detects a Flag or 
Abort, it stores the partial character left-justified in an 
RxFIFO entry. (That is, in the MSBits of the byte, 
regardiess of RxLength.) The Receiver saves the 
number of bits received in the last byte in the 
RxResidue field of the Receive Command/Status 
Register (RCSR11-9). RxResidue remains available 
until the end of the next received frame. Software can 
use the Receive Status Block feature as described ina 
later section, to store the RCSR in memory, which 
reduces processing requirements still further. 


Conversely, to send a frame that doesn't contain an 
integral number of characters, software must ensure 
that the number of bits in the last character of the 
frame is written into the TxResidue field of the 
Channel Command/Status Register (CCSR4-2). This 
must happen before the Transmitter takes the last 
character out of the TxFIFO 


Figure 40 shows the CCSR. The Transmit Control 
Block feature can be used to set the TxResidue value 
for each block under DMA control, without intervention 
by processor software. The active bits of a partial 
character must be right-justified, that is, they must be 
the LSBits of the last character. If the TxParEnab bit 
in the Transmit Command / Status Register (TCSRS5) 
is 1 specifying parity generation, for a partial character 
the Transmitter sends the parity bit after the number of 
bits specified by TxResidue, while in other characters 


‘the parity bit is the last one of the character length 


specified by TxLength (TMR4-2). 


The encoding of RxResidue and TxResidue is as for 
RxLength and TxLength: 000 specifies that the last 
character contains eight bits, while 001-111 specify 1 
to 7 bits respectively. 


Handling a Received Abort 


The 16C32 can report a received Abort sequence to 
software in two separate ways. The later section 
Status Handling will note that the IUSC sets the 
Break/Abort bit in the Receive Command/Status 
Register (RCSR5) immediately when it recognizes an 
Abort sequence. This notification is not tied to a 
specific point in the received data stream. 


The same section will also note that, if the QAbort bit 
in the Receive Mode Register (RMR8) is 1, the 16C32 
queues Abort conditions through the RxFIFO. From 
there, they eventually appear as the Abort/PE bit 
(RCSR2) of the last character of the frame -- the one 
that has RxBound (RCSR4) set to 1. (If QAbort is 0, 
the IUSC uses this RxFIFO and RCSR bit for Parity 
Error indication as on the 16C31.) 


With other devices, software typically handles Abort 
conditions by enabling an interrupt when one is 
detected, and at that point ignoring/purging all 
received data and forcing the receiver into Hunt mode 
for the next frame. 


With the 16C32, software can handle Aborts more 
efficiently/elegantly by setting QAbort to 1 and using 
the Receive Status Block feature to store the RCSR 
status in memory for each frame, as described in the 
later section Receive Status Blocks. Software can 
then examine this status word for each "frame"; any 
one that has Abort/PE set isn't a proper frame in that it 
ended with an Abort sequence rather than a Flag. 


HDLC / SDLC Loop Mode 


This mode applies only to the Transmitter. Software 
can select it by programming the TxMode field of the 
Channel Mode Register (CMR11-8) as 1110 while 
programming the RxMode field (CMR3-0) as 0110 to 
select HDLC / SDLC mode. 


Loop mode is useful in networks in which the nodes or 
stations form a physical loop. Except for one station 
that acts in a "Primary" or Supervisory role, each must 
pass the data it receives from the "preceding" station 
to the "following" one. The only time that a secondary 
station can break out of this echoing mode is when it 
receives a special sequence called a "Go Ahead" and 
it has something to send. 


Again, this is a specific protocol and we can define 
how certain other register fields should be program- 
med for its intended application. For IBM SDLC Loop 
compatibility, software should program the Transmit 
Mode Register (TMR) with 6702,,. This enables the 
Transmitter with NRZI-Space encoding, 16-bit CCITT 
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CRC, no parity, and 8 bit characters. Software also 
should program the Txldle field in the Transmit 
Command/Status Register (TCSR10-8) with 000 to 
select Flags as the idle line state. 


The two MSBits of the TxSubMode field (CMR15-14) 
control what the Transmitter does if an Underrun con- 
dition occurs, that is, if it needs a character to send but 
the TxFIFO is empty. The available choices are simi- 
lar to those in normal HDLC/SDLC mode but the 
Transmitter has a wider range of subsequent actions: 
CMRI15-14 Response to Underrun 
00 The Transmitter sends an Abort 
("Go Ahead") sequence 
consisting of a zero followed 
by seven consecutive ones, and 
then stops sending and reverts 
to echoing the data it 
receives. Zilog doesn't 
recommend this option in IBM 
SDLC Loop applications because 
only the Primary station 
should issue a "Go Ahead" 
sequence (and a primary 
station should be in regular 
HDLC/SDLC mode). 


Like 00 except that the Abort 
includes 15 one-bits. 


01 


10 The Transmitter sends Flags on 
an Underrun, until another 
frame is ready or until 
software clears CMR13 to 0. 

ll The Transmitter sends its 


accumulated CRC followed by 
Flags on an Underrun, until 
another frame is ready to 
transmit or until software 
clears CMR13 to 0. Zilog 
doesn't recommend this option 
either, because the frame 
format probably hasn't been 
met when there's an underrun. 


The CMR13 bit plays a different role when the Trans- 
mitter is first being enabled to "insert this station into 
the loop", as compared to normal operation thereafter. 
Before software programs the Channel Mode Register 
for SDLC Loop mode and enables the Transmitter, the 
TXD pin carries continuous ones. If software initially 
enables the Transmitter with CMR13 being 0, the part 
continues to output Ones on TxD. When CMRi3 is 1 
after software first enables the Transmitter, the |USC 
sends zeroes on TxD until the Receiver detects a "Go 
Ahead" sequence (01111111). At this point the |IUSC 
starts passing data from RxD to TxD with a 4-bit delay, 
and sets the OnLoop bit in the Channel 
Command/Status Register (CCSR7; see Figure 40). 


On Loop stays 1 unless the part is reset or software 
programs the TxMode field to a different value. Once 
OnLoop is 1 and the IUSC is repeating data from RxD 
to TxD, CMR13 controls what the Transmitter does 
when it receives a(nother) Go Ahead sequence. 





RCCF | RCCF | Clear | DPLL | DPLL | DPLL On | Loop | Ctr 

D TxResid R 
Ovflo | Avail | RCCF | Sync | 2Miss | 1Miss BrErege Loop | Send |Bypass eet esetver 
15 14 13 12 11 10 9g 8 7 6 5 4 3 2 1 0 





Figure 40. The Channel Command/Status Register (CCSR) 


If CMR13 is 0, the IUSC just keeps repeating data, 
including the "GA". If CMR13 is 1 when the Receiver 
detects another "Go Ahead", the Transmitter changes 
the last bit of the GA from 1 to 0 (making it a Flag), 
sets the LoopSend bit (CCSR6) and proceeds to start 
sending data. (If there's no data available in the 
TxFIFO it keeps sending Flags, otherwise it sends the 
data in the TxFIFO.) 


When the Transmitter has been sending data and en- 
counters either a character marked as "EOF/EOM'", or 
an underrun condition when CMR15=1, CMR13 de- 
termines how it proceeds. If CMR13 is 1 in either of 
these situations, the Transmitter stays active and 
sends Flags or additional frames as they become 
available in the TxFIFO. If CMR13 is 0 after the IUSC 
has sent a closing Flag or an idle Flag, it clears the 
LoopSend (CCSR6) bit and returns to repeating data 
from RxD onto TxD. 


CMR12 controls whether the Transmitter sends idle 
Flags with shared zero bits, as described for normal 
HDLC / SDLC mode. 


Cyclic Redundancy Checking (CRC) 


The IUSC will send and check CRC codes only in 
synchronous modes, namely External Sync, Mono- 
sync, Slaved Monosync, Bisync, Transparent Bisync, 
HDLC/SDLC, HDLC/SDLC Loop, and 802.3 modes. 
The TxCRCType and RxCRCType fields in the 
Transmit and Receive Mode Registers (TMR12-11 
and RMR12-11) control how the Transmitter and 
Receiver accumulate CRC codes. 


00 in either field selects the 16-bit CRC-CCITT poly- 
nomial X'§+X'24+x5+1. In HDLC, HDLC Loop, and 
802.3 modes, the Transmitter inverts each CRC 
before sending it, the Receiver checks for remainders 
of FOB8,., and the TxCRCStart and RxCRCStart bit(s) 
should be programmed as 1 to start the CRC 
generators with all ones. In other synchronous modes 
the Transmitter sends accumulated CRCs normally 
and the Receiver checks for all-zero remainders. 


01 in either field selects the CRC-16 polynomial x'®+ 
x'5+x2+1, The Transmitter sends accumulated CRCs 
normally and the Receiver checks for all-zero remain- 
ders. This choice is not compatible with HDLC, HDLC 
Loop, and 802.3 protocols, and in these modes CRC- 
16 will not operate correctly even between USC family 
Transmitters and Receivers. 


10 in TxCRCType or RxCRCType selects the 32-bit 
Ethernet polynomial x92+x?64+x254 224x164 12411410 
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+X8+X7+X5+X4+X2+X+1. In HDLC, HDLC Loop, and 
802.3 modes, the Transmitter inverts each CRC 
before transmitting it, the Receiver checks for remain- 
ders equal to C704DD7B,,, and the TxCRCStart and/ 
or RxCRCStart bit(s) should be programmed as 1 to 
start the CRC generator(s) with all ones. In other syn- 
chronous modes the Transmitter sends CRCs_ nor- 
mally and the Receiver checks for all-zero remainders. 


Zilog reserves the value 11 in TxCRCType or 
RxCRCType for future product enhancements; it 
should not be programmed. 


The TxCRCStart and RxCRCStart bits (TMR12 and 
RMR12) control the starting value of the Transmit and 
Receive CRC generators for each frame or message. 
A 0 in this bit selects an all-zero starting value and a 1 
selects a value of all ones. In HDLC, HDLC Loop, and 
802.3 modes these bits should be 1. 


The Transmitter and Receiver automatically clear their 
CRC generators to the state selected by these 
CRCStart bits at the start of each frame. The Trans- 
mitter does this after it sends an opening Sync or Flag 
sequence. The Receiver does so each time it recog- 
nizes a Sync or Flag sequence (it may be the last one 
before the first character of the frame or message). 
For special CRC requirements, the Clear Rx and Tx 
CRC commands give software the ability to clear the 
CRC generators at any time. See the later section 
Commands for a full description of these operations. 


The TxCRCEnab and RxCRCEnab bits (TMR9 and 
RMRQ) control whether the IUSC processes trans- 
mitted and received characters through the respective 
CRC generators. A 0 excludes characters from the 
CRC while a 1 includes them. The Transmitter cap- 
tures the state of TxCRCEnab with each character as 
it's written into the TxFIFO, so that software can 
change the bit dynamically for different characters. 


If the TxCRCatEnd bit (TMR8) is 1 and the TxMode 
field (CMR11-8) specifies a synchronous mode, the 
Transmitter sends the contents of its CRC generator 
after sending a character marked as EOF/EOM. If 
TxCRCatEnd is 0 the Transmitter doesn't send a CRC 
after such a character. (A character can be marked as 
EOF/EOM if software writes a command to the 
Transmit Command/Status Register (TCSR), or when 
the Transmit DMA channel or software writes one or 
two characters to the TxFIFO so that the Transmit 
Character Counter decrements to zero.) Whether or 
not it sends a CRC, the Transmitter then sends a Sync 
or Flag sequence, depending on the protocol. 


In synchronous modes, the MS 1 or 2 bits of the 
TxSubMode field (CMR15 and in some modes also 
CMR14) control whether the Transmitter sends the 
contents of its CRC generator if it encounters a 
Transmit Underrun condition, that is, if it needs a 
character to send but the TxFIFO is empty. Whether 
or not it sends a CRC, the Transmitter then sends a 
Sync or Flag sequence, depending on the protocol. 


On the receive side, in synchronous modes other 
than HDLC/SDLC, HDLC/SDLC Loop, and 802.3, 
there's a two character delay between the time the 
Receiver places each received character in the 
RxFIFO and when it processes (or doesn't process) 
the character through the CRC generator. Therefore, 
software can examine each received character and set 
RxCRCEnab appropriately to exclude certain char- 
acters from CRC checking, if it can do so before the 
next one arrives. The Receiver doesn't introduce this 
delay in HDLC/SDLC, HDLC/SDLC Loop, or 802.3 
mode, because in these modes all characters in each 
frame should be included in the CRC calculation. 


Figure 41 shows how a Receiver routes data to the 
Receive CRC generator differently in HDLC/SDLC, 
HDLC/SDLC Loop, and 802.3 modes than in other 
synchronous modes. In these three modes, the 
Receiver shifts each bit from RxD into the CRC 
generator when it shifts the bit into its main shift 
register. In other sync modes, the Receiver passes 
the data through a second shift register located 
between the main shift register and the CRC 
generator. This second shift register is (RxLength) 
bits long, and gives the software time to decide 
whether to include each received character in the CRC 
calculation. 


The Receive CRC generator constantly checks 
whether its contents are "correct" according to the kind 
of CRC specified by the RxCRCType field (RMR12- 
11). In some modes this simply means whether it 
contains an all-zero value. The CRC generator 
provides a corresponding Error output that the 
Receiver captures in the RxFIFO with each received 
character. This bit migrates through the RxFIFO with 
each character and eventually appears as_ the 
CRCE/FE bit in the Receive Command/Status 
Register (RCSR3). Software should ignore this bit for 
all characters except the one associated with the end 
of each message or frame (it's almost always 1). 


The CRCE bit that's important is the one that reflects 
the output of the CRC generator after the Receiver 
has shifted the last bit of the CRC into it. But the 
operating difference described above affects which 
character this bit is associated with. The Receiver 
always places the CRC code itself in the RxFIFO; if 
RxLength calls for 8-bit characters the CRC 
represents either 2 or 4 characters. In HDLC/SDLC or 
802.3 mode, the CRCE bit associated with the last 
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character of the CRC is the one that shows the CRC- 
correctness of the frame. But in the’ other 
synchronous modes, the CRCE bit of interest is the 
one with the second character after the last character 
of the CRC. This means that the Receive Status 
Block feature can't be used to capture the CRC 
correctness of received messages in Transparent 
Bisync mode. 


Note that the CRCE/FE bit can represent the status at 
the time that an RxBound character was read from the 
RxFIFO, or the status of the oldest 1 or 2 characters 
that are still in the RxFIFO, as described !ater in 
Status Reporting. 


Because the Receiver places all the bits of each 
received CRC in the RxFIFO, the IUSC can be used 
for CRC-pass-through applications like bridges and 
routers. This is not true of all serial controllers. 
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Figure 41. A Model of the Receive Datapath 
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Parity Checking 

The IUSC can handle a Parity bit in each character in 
either asynchronous or synchronous modes, although 
some synchronous protocols use CRC checking only. 


lf the TxParEnab bit in the Transmit Mode Register 
(TMRS) is 1, the Transmitter creates a parity bit as 


specified by the TxParType field (TMR7-6) and sends 
it with each character. Similarly, if the RxParEnab bit 
(RMRS) is 1, the Receiver checks a parity bit in each 
received character, according to the RxParType field 
(RMR7-6). 


The IUSC interprets TxParType and RxParType as 
follows: 


XMR7-6 Type of Parity 


00 Even 
01 Odd 
10 Zero 
11 One 


For unencoded data, 10/Zero is the same as "Space 
parity" and 11/One is the same as "Mark parity". 


TxParEnab and TxParType are "global states" in that 
the IUSC doesn't carry these bits thru the TxFIFO with 
each character. 


In asynchronous modes, the Transmitter and Receiver 
handle the parity bit as an additional bit after the 
number of bits specified by the TxLength and 
RxLength fields (TMR4-2 and RMR4-2)._ In synch- 
ronous modes they handle the parity bit as the last 
(most significant) bit of that number. The Receiver 
includes a parity bit in the data characters in the 
RxFIFO and Receive Data Register (RDR), except in 
asynchronous modes with 8 bit data. 


In HDLC/SDLC protocols the 16C32's Receiver can 
queue either a Parity Error or an Abort indication 
through the RxFIFO, but not both. Regardless of the 
protocol, in order to have the Receiver check parity, 
software should ensure that the QAbort bit in the 
Receive Mode Register (RMR8) is 0. 


If QAbort is 0, RxParEnab is 1, and the Receiver finds 
that the parity bit of a received character is not as 
specified by RxParType, it sets a Parity Error bit. This 
bit accompanies the character through the RxFIFO, 
eventually appearing as the Abort/PE bit in the 
Receive Command / Status Register (RCSR2). The 
Abort/PE bit can represent a latched interrupt bit, or 
the status at the time that an RxBound character was 
read from the RxFIFO, or the status of the oldest 1 or 
2 characters that are still in the RxFIFO, as described 
in the next section. 


Status Reporting 


The most important status reported by the Transmitter 
and Receiver is available in the LSBytes of the 
Transmit and Receive Command / Status Registers 
(TCSR and RCSR). Figures 43 and 44 show the 
format of these registers. It will be helpful to describe 
some common characteristics of these status bits 
before discussing each individually. 


When software writes and reads transmit and received 
data directly to and from a serial controller, it can read 
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and write status and control registers as needed to 
handle the overall communications process. But the 
IUSC's integrated DMA channels often handle the data 
without software/processor intervention. Because of 
this, software needs other means of controlling the 
transmit and receive processes and tracking their 
status. These means include the Transmit and 
Receive Character Counters and the Transmit Control 
Block and Receive Status Block features. Later 
sections describe these features in considerable detail. 
For now we just note that Receive Status Blocks allow 
the Receive DMA channel to store a version of the 
RCSR in memory, either with the received data or with 
DMA control information. Such stored status differs 
slightly from that which software can read from the 
RCSR. 


Software can program the IUSC to assert its Interrupt 
Request output (/INT) based on certain bits in the 
TCSR and RCSR. Chapter 6 covers interrupts in 
detail; for now we'll just note that the IUSC typically 
sets one of these bits when a specified event occurs 
or a specified condition starts. Such a bit typically 
remains 1 until host software clears or "unlatches" it by 
writing a 1 to it. This means that the device won't re- 
quest another interrupt for the same condition until 
software has written a 1 to the bit. For the two inter- 
rupts that reflect the start of an ongoing condition, 
IdleRcved and the "break" sense of Break/Abort, the 
Receiver doesn't clear the RCSR bit until the software 
has written a 1 to unlatch the bit, and the condition has 
ended. 


Five of the bits in the RCSR (ShortF/CVType, 
RxBound’, CRCE/FE, Abort/PE, and RxOver) are 
associated with particular received characters. The 
Receiver queues these bits through the RxFIFO with 
the characters. The corresponding bits in the RCSR 
may reflect the status of the oldest character(s) in the 
FIFO, or that of the character last read out of the 
FIFO, as described in the next few paragraphs. 


In order for these queued interrupt features to operate 
properly, software should set the WordStatus bit in 
the Receive Interrupt Control Register (RICR3) to 1 
before it reads data from the RxFIFO/RDR 16 bits at a 
time, and to 0 before it reads data 8 bits at a time. 


The RxBound, Abort/PE, and RxOver bits actually 
operate differently in the RCSR depending on whether 
software has enabled each to act as a source of inter- 
rupts. If the Interrupt Arm (IA) bit* in the Receive 
Interrupt Control Register (RICR) for one of these bits 
is 1, the IUSC sets the RCSR bit to 1 when a char- 


3 Previous USC documentation called RxBound "CV/EOF/EOT". 


4 Previous USC documentation called the bits that control individual interrupt 
sources Interrupt Enable (IE) bits, the same as those that enable entire interrupt 


types. 


acter having the subject status becomes the oldest 
one in the RxFIFO, or the second-oldest with 
WordStatus=1, and once one of these bits is 1, it stays 
that way until software writes a 1 to it. (The IUSC 
doesn't actually set the Receive Status IP bit to 
request an interrupt for one of these bits, until software 
or the Receive DMA channel reads the associated 
character from RDR.) 


For ShortF/CVType and CRCE/FE, and for RxBound, 
Abort/PE, and RxOver when the associated IA bit is 0, 
if the last time that software or the Receive DMA 
channel read the RxFIFO via the RDR, the IUSC 
provided a character marked with RxBound status, 
then these RCSR bits reflect the status of that 
character. This is true only until software reads the 
(MSByte of) RCSR, or the Receive DMA channel 
stores it in the Receive Status Block, or until software 
or the Receive DMA channel reads the RDR again. 


Start for RxBound, 
Abort/PE, or RxOver: 


What's the 
corresponding IA 
bit in the RICR? 


For ShortF/CVType and CRCE/FE, and for RxBound, 
Abort/PE, and RxOver when the associated IA bit is 0, 
if the last time that software or the Receive DMA 
channel read the RxFIFO via the RDR, the character 
returned (both of the characters returned) had 
RxBound=0, or if software has read the (MSByte of 
the) RCSR or the Receive DMA channel has stored it 
in a Receive Status Block since the last time either 
one read the RDR, then the RCSR bit reflects the 
status of the oldest character(s) in the RxFIFO, if any. 
In this latter case, if the RxFIFO is empty the status bit 
is not defined. If the WordStatus bit is 1 in the 
Receive Interrupt Control Register (RICR3) and there 
are two or more characters in the FIFO, the status bit 
is the inclusive OR of the status of the oldest two 
characters in the FIFO. Otherwise the bit reflects the 
status of the oldest character in the FIFO. Just in 
case that wasn't perfectly clear, the flowchart of Figure 
42 presents the same information. 


Provide the state of a latch 
that's set when a character 
with this condition becomes 
the oldest in the RxFIFO 
(or the 2nd-oldest with 
WordStatus=1), and is cleared 
when SW writes a 1 to this bit 


Has the (MSByte 
of the) RCSR been 
read since then? 


Did the last read 
from the RDR have 
RxBound=1? 


(The bit is not How many 
defined!) characters are in 


the RxFIFO?? 


Provide the status of 


the oldest character 
in the RxFIFO 


Provide the saved 
status of the 
RxBound character 


What's the 
WordStatus bit 
(RICR3)? 


Provide the inclusive 
OR of the status of the 
two oldest characters 

in the RxFIFO 





Figure 42. How the IUSC Provides the "Queued" Status Bits In the RCSR 
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Figure 43. The Transmit Command/Status Register (TCSR) 


Detailed Status in the TCSR 


The Transmitter sets the PreSent bit (TCSR7) in a 
synchronous mode, when it has finished sending the 
Preamble specified in the TxPreL and TxPrePat fields 
of the Channel Control Register (CCR). The IUSC can 
request an interrupt when this bit goes from 0 to 1 if 
the PreSent IA bit in the Transmit Interrupt Control 
Register (TICR7) is 1. Software must write a 1 to 
PreSent to unlatch and clear it, and to allow further 
interrupts if TICR7 is 1; writing a 0 to PreSent has no 


effect. See the later section Between Frames, Mes- 
sages, or Characters for more information on 
Preambles. 


The Transmitter sets the IdleSent bit (TCSR6) in any 
mode, when it has finished sending "one unit" of the 
Idle line condition specified in the Txlidle field in the 
MSByte of this TCSR. If the Idle condition is Syncs or 
Flags as described later in Between Frames, Mes- 
sages, or Characters, the unit is one character or 
sequence and the flag and interrupt can recur for each 
one sent. For any other Idle condition, the 
Transmitter sets the flag and interrupt only once, when 
it has sent the first bit of the condition. The IUSC can 
request an interrupt when this bit goes from 0 to 1 if 
the IdleSent IA bit in the Transmit Interrupt Control 
Register (TICR6) is 1. Software must write a 1 to 
IdleSent to unlatch and clear it, and to allow further 
interrupts if TICR6 is 1; writing a O to IdleSent has no 
effect. 


The Transmitter sets the AbortSent bit (TCSRS5) in 
HDLC/SDLC or HDLC/SDLC Loop mode, when it has 
finished sending an Abort sequence. The IUSC can 
request an interrupt when this bit goes from 0 to 1 if 
the AbortSent IA bit in the Transmit Interrupt Control 
Register (TICRS) is 1. Software must write a 1 to 
AbortSent to unlatch and clear it, and to allow further 
interrupts if TICRS is 1; writing a 0 to AbortSent has no 
effect. See the earlier sections HDLC/SDLC Mode 
and HDLC/SDLC Loop Mode for more information on 
Abort sequences. 


The Transmitter sets the EOF/EOM Sent bit (TCSR4) 
in a synchronous mode, when it has finished sending a 
closing Flag or Syne sequence. The IUSC can re- 
quest an interrupt when this bit goes from 0 to 1 if the 
EOF/EOM Sent IA bit in the Transmit Interrupt Control 
Register (TICR4) is 1. Software must write a 1 to 
EOF/EOM Sent to unlatch and clear it, and to allow 
further interrupts if TICR4 is 1; writing a O has no 
effect. See the later section Between Frames, 


Messages, or Characters for more information on 
closing Flags and Syncs. 


The Transmitter sets the CRCSent bit (TCSR3) in a 
synchronous mode, when it has finished sending a 
Cyclic Redundancy Check sequence. The IUSC can 
request an interrupt when this bit goes from 0 to 1 if 
the CRC Sent IA bit in the Transmit Interrupt Control 
Register (TICR3) is 1. Software must write a 1 to 
CRCSent to unlatch and clear it, and to allow further 


_ interrupts if TICRS is 1; writing a 0 has no effect. See 
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the section Cyclic Redundancy Checking for more 
information on CRC's. 


The read-only bit AllSent (TCSR2) is 0 in asynch- 
ronous modes, while the Transmitter is sending a 
character. Software can use this bit to figure out when 
the last character of an async transmission has made 
it out onto TxD, before changing the mode of the 
Transmitter. 


The Transmitter sets the TxUnder bit (TCSR1) in any 
mode, when it needs another character to send but the 
TxFIFO is empty. It does this even in asynchronous 
modes. The IUSC can request an interrupt when this 
bit goes from O to 1 if the TxUnder IA bit in the 
Transmit Interrupt Control Register (TICR1) is 1. 
Software must write a 1 to TxUnder to unlatch and 
Clear it, and to allow further interrupts if TICR1 is 1; 
writing a O has no effect. The Transmitter sets 
TxUnder one or two clocks before the current char- 
acter is completely sent on TxD. 


The read-only bit TxEmpty (TCSRO) is 1 when the 
TxFIFO is empty, or 0 if it contains 1 or more 
characters. 


Detailed Status in the RCSR 


The IUSC sets the read-only 2na3e bit (RCSR15) to 
1 when software or the Receive Di.’4 cnannel reads 
data from the RDR, there are two or more characters 
in the RxFIFO, and the Receiver marked ““s second- 
oldest one with one or more of RxBound, Abort/PE, or 
RxOver status. (The bit's name stands for Second 
Byte Exception.) The IUSC clears this bit to 0 wien 
software or the Receive DMA channel reads data from 
the RxFIFO/RDR, there are two or more characters in 
the RxFIFO, and the Receiver didn't mark the second- 
oldest one with any of these tnree condiions. If 
software or the Receive DMA channel reads d2ta from 
the RDR when there's only one character in it, this bit 
is undefined until the next time one of them reads 
RDR. 





__RCmd (WO) _ aoe ShortF/ Idle | Break | Rx | CRCE| Abort | Rx Rx 
2ndBE 1stBE CVType Reved | /Abort | Bound! /FE /PE Over | Avail 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 





Figure 44. The Recelve Command/Status Register (RCSR) 


The IUSC sets the read-only 1stBE bit (RCSR14) to 1 
when software or the Receive DMA channel reads 
data from the RDR, and the Receiver marked the 
oldest character read with one or more of RxBound, 
Abort/PE, or RxOver status. (The bit's name stands 
for First Byte Exception.) The IUSC clears this bit to 0 
when software or the Receive DMA channel reads 
data from the RDR, and the Receiver didn't mark the 
oldest character with any of these three conditions. 


The Receiver queues a ShortF/CVType bit through 
the RxFIFO with each character. RCSR8 may reflect 
the status at the time that an RxBound character was 
read from the RxFIFO, or the status associated with 
the oldest 1 or 2 character(s) still in the RxFIFO, as 
described earlier in this Status Reporting section. Ina 
stored Receive Status Block it always represents the 
status of the preceding RxBound character. 


This bit will be 1 only in HDLC/SDLC or Async with 
Code Violation (1553B) mode, and only for characters 
that the Receiver also marks with RxBound=1. When 
the RxSubMode field (CMR7-4) specifies Address and 
possibly Control field processing in HDLC/SDLC 
mode, the Receiver sets this bit for the last character 
of a frame if it hasn't come to the end of the specified 
field(s) by the end of the frame. 


In Asyne with Code Violations (1553B) mode, this bit 
identifies which of the two types of Code Violation 
introduced each received word. A 0 indicates a Data 
word and a 1 indicates a Command/Status word. 
When the RxSubMode bit CMR4 is 1, signifying that 
each word includes more than 8 data bits, this bit is 
valid with the second byte of each received word (the 
one marked with RxBound status). 


The Receiver sets the ExitedHunt bit (RCSR7) in any 
mode, when it leaves its Hunt state. In Async modes 
this happens right after software enables the Receiver. 
In External Sync mode, the Receiver leaves Hunt 
state when the Enable/Sync signal on /DCD goes from 
high to low. In Monosyne, Bisync, or Transparent 
Bisync mode the Receiver leaves Hunt state when it 
recognizes a Sync sequence. In HDLC/SDLC mode 
the Receiver leaves Hunt state when it recognizes an 
opening Flag. In 802.3 (Ethernet) mode, if software 
has enabled address checking the Receiver leaves 
Hunt state when it matches the Address at the start of 
a frame, otherwise it does so after detecting the start 
bit at the end of the Preamble. 


The IUSC can request an interrupt when this bit goes 
from 0 to 1 if the ExitedHunt IA bit in the Receive 
Interrupt Control Register (RICR7) is 1. Software 
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must write a 1 to ExitedHunt to unlatch and clear it, 
and allow further interrupts if RICR7 is 1; writing a 0 
has no effect. 


The Receiver sets the IdleRceved bit (RCSR6) when it 
samples RxD as one for 15 consecutive RxCLKs in 
HDLC/SDLC mode, or for 16 consecutive RxCLKs in 
any other mode. The IUSC can request an interrupt 
when this bit goes from 0 to 1 if the IdleRcved IA bit in 
the Receive Interrupt Control Register (RICR6) is 1. 
Software must write a 1 to IdleRcved to unlatch it, and 
to allow further interrupts if RICR6 is 1; writing a 0 has 
no effect. The device doesn't actually clear RCSR6 
until software has written a 1 to unlatch it, and RxD 
has gone to 0 to end the idle condition. (IdleRcved 
isn't useful in Async modes that use a 16X, 32X, or 
64X clock. In these cases keep RICR6=0 to avoid 
interrupts, and ignore RCSR6.) 


The Receiver sets the Break/Abort bit (ROSRS5) in an 
asynchronous mode when it detects a Break condition, 
that is, when it samples the Stop bit of a character as 
0, and all the preceding data bits (and the parity bit if 
any) have also been 0. It sets the bit in HDLC/SDLC 
mode when it detects seven consecutive 1s, i.e., an 
Abort or Go Ahead sequence. 


Break/Abort is not associated with a particular point in 
the received data stream, for either the Break or Abort 
condition. (But see the description of “Abort/PE" 
below for an Abort indication that is queued with 
received data.) 


The IUSC can request an interrupt when this bit goes 
from 0 to 1 if the Break/Abort IA bit in the Receive 
Interrupt Control Register (RICR5) is 1. Software 
must write a 1 to Break/Abort to unlatch it, and to allow 
further interrupts if RICRS is 1; writing a O has no 
effect. In async modes, the IUSC doesn't actually 
clear RCSR5 until software has written a 1 to unlatch 
it, and RxD has gone to 1 to end the break condition. 


The Receiver queues a RxBound bit through the 
RxFIFO with each received character. It sets the bit 
with a character that represents the boundary of a 
logical grouping of data on the line, but this indication 
isn't visible to software until the character is the oldest 
one in the RxFIFO. 


As described earlier in this Status Reporting section, 
RCSR4 may represent an interrupt bit, or the status 
associated with the oldest 1 or 2 character(s) still in 
the RxFIFO; or may be 1 if a RxBound character was 
just read from the RxFIFO. Since the Receive Status 
Block feature stores the RCSR in memory after each 


character that the Receiver marks with this bit set, a 
Receive Status Block always shows RxBound® as 1. 


In HDLC/SDLC mode the Receiver sets RxBound for 
the last complete or partial character before an ending 
Flag or Abort. In Transparent Bisync mode it sets this 
bit for an ENQ, EOT, ETB, ETX, or ITB character that 
follows a DLE. In External Sync or 802.3 (Ethernet) 
mode the Receiver sets this bit for the character just 
completed or partially assembled when the /DCD pin 
went High. In Nine-Bit mode it sets this bit for an 
address character. In the Async with Code Violations 
(1553B) mode, it sets this bit for the second character 
of each received word if the CMR13 bit is 1 to enable 
word lengths greater than 8 bits, or for every character 
if not. Note that the Receiver never sets this bit in 
other modes, including Monosync and Bisync modes. 


The IUSC can request an interrupt when software or 
the Rx DMA channel reads a character from the RDR 
that has this bit set, if the RxBound IA bit in the Re- 
ceive Interrupt Control Register (RICR4) is 1. In this 
case software must write a 1 to RxBound to unlatch it 
and allow further interrupts; writing a 0 has no effect. 


The Receiver queues a CRCE/FE bit through the 
RxFIFO with each received character. RCSR3 may 
represent the status at the time that a RxBound char- 
acter was read from the RxFIFO, or the status associ- 
ated with the oldest 1 or 2 character(s) still in the 
RxFIFO, as described earlier in this Status Reporting 
section. In a stored Receive Status Block it repre- 
sents the status from the previous character, which in 
turn represents the CRC-correctness of the frame in 
802.3 and HDLC/SDLC mode. 


In synchronous modes the Receiver makes CRCE/FE 
0 if its CRC generator showed "correct" status when it 
stored the character in the RxFIFO, or 1 if the CRC 
generator wasn't correct. See the earlier section 
Cyclic Redundancy Checking for more information. In 
asynchronous, isochronous, or Nine-Bit mode the 
Receiver makes this bit 1 to show a Framing Error if it 
samples the associated character's Stop bit as 0. 


The Receiver queues an Abort/PE bit through the 
RxFIFO with each received character. RCSR2 may 
represent an interrupt bit, or the status at the time that 
a RxBound character was read from the RxFIFO, or 
the status associated with the oldest 1 or 2 char- 
acter(s) still in the RxFIFO, as described earlier in this 
Status Reporting section. In a stored Receive Status 
Block it may represent an interrupt bit or the status of 
the previous 1 or 2 character(s). 


If the QAbort bit in the Receive Mode Register 
(RMR8) is 0, the Receiver sets this bit to show a Parity 
Error for a character if RxParEnab (RMRS) is 1 and 


5 Previous USC documentation called RxBound "CV/EOF/EOT" 
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the character's parity bit doesn't match the condition 
specified by the RxParType field. See the earlier 
section Parity Checking for more information. 


In HDLC/SLDC mode with the QAbort bit 1, the 
Receiver sets this bit (along with RxBound) for a 
character that was followed by an Abort sequence. 


The |USC can request an interrupt when software or 
the Receive DMA channel reads a character from the 
RDR that has this bit set, if the Abort/PE IA bit in the 
Receive Interrupt Control Register (RICR2) is 1. In 
this case software must write a 1 to Abort/PE 
(RCSR2) to unlatch it and allow further interrupts; 
writing a 0 to RCSR2 has no effect. 


The Receiver queues a RxOver bit through the 
RxFIFO with each received character. It sets the bit to 
indicate a Receive FIFO overrun, but the overrun isn't 
visible to software until the character that caused it is 
the oldest one in the RxFIFO. 


As described earlier in this Status Reporting section, 
RCSR1 may represent an interrupt bit, or the status at 
the time a RxBound character was read from the 
RxFIFO, or the status associated with the oldest 1 or 2 
character(s) still in the RxFIFO. In a stored Receive 
Status Block this bit may represent an interrupt bit or 
the status of the previous character. 


The Receiver sets this bit to 1 for the first character for 
which there was no room, which overwrites its 
predecessor in the RxFIFO. Once this happens, the 
Receiver doesn't store any more received characters 
in the RxFIFO, until software writes a command that 
purges the RxFIFO to the RTCmd field in the Channel 
Command / Address Register (CCAR15-11). 


The IUSC can request an interrupt when software or 
the Rx DMA channel reads a character from the RDR 
that has this bit set, if the RxOver IA bit in the Receive 
Interrupt Control Register (RICR1) is 1. In this case, 
software must write a 1 to RxOver to unlatch it and 
allow further interrupts; writing a 0 has no effect. 


The read-only bit RxAvall (RCSRO) is 1 if the RxFIFO 
contains 1 or more characters, or 0 if it's empty. 


DMA Support Features 


When software writes and reads all the data to and 
from a serial controller, it can maintain its own 
counters and length-tracking mechanisms, and can 
use them to tell when to read status and issue 
commands. But in DMA applications we would like to 
"decouple" the processor and its software from such 
intimate and real-time involvement with the transmit 
and receive processes. This is only possible if we 
include features in the serial and/or DMA controllers, 
by which they can figure out the length of frames or 
messages, and change parameters and save status 


information at appropriate points, with as little proces- 
sor software involvement as possible. 


The IUSC features that support such operation include 
the Receive and Transmit Character Counters, the 
RCC FIFO that stores the length of received frames, 
the Transmit Control Block feature that allows the Tx 
DMA channel to fetch control information for each 
frame from memory, and the Receive Status Block 
feature that allows the Rx DMA channel to store status 
for each frame in memory. The following subsections 
describe these features. 


The Character Counters 


The Transmitter includes a 16-bit Transmit Character 
Counter (TCC) that software can use to control the 
length of transmitted frames and messages in DMA 
applications. The Receiver includes a similar Receive 
Character Counter (RCC) that software can use to 
record and save the length of frames and messages in 
DMA applications. Software can also use the RCC to 
specify the maximum frame/message length allowed 
in such applications. 


While most of this section describes these features in 
terms of the length of frames and messages in 
synchronous protocols, they may be useful in asynch- 
ronous work as well. In particular, for Asyne with 
Code Violations (1553B) transmitting, software can 
use the TCC and Transmit Control Block features to 
control which type of Code Violation (Command/ 
Status or Data) to send, for each series of words of 
the same type. Similarly, 1553B receiving software 
can use the RCC and Receive Status Block features 
to make the Receive DMA channel store the type of 
Code Violation after each received word. A later 
subsection describes these features more fully. 


Figures 45 and 46 show the structure of the TCC and 
RCC features, respectively. Software can write the 
16-bit Transmit Count Limit Register (TCLR) at any 
time, to define the length of the next transmitted 
message(s) or frame(s). Similarly, it can write the 16- 
bit Receive Count Limit Register (RCLR) at any time, 
to define the maximum length of future received mes- 
sages and frames. Software can also use the Trans- 
mit Control Block feature to make the IUSC automat- 
ically fetch a new value for the TCLR and TCC from 
memory before each block of characters. The TCLR 
and RCLR can be read back at any time. The device 
never changes their values except to clear them to 
zero at reset time, and when it loads TCLR from a 32- 
bit Transmit Control Block. 


Writing the TCLR or RCLR doesn't have any immedi- 
ate effect on the TCC or RCC feature. Only when one 
of several events occurs does the IUSC load the value 
from TCLR or RCLR into the actual 16-bit character 
counter. If the value in TCLR or RCLR is zero at that 


time, the device disables the TCC or RCC feature, 
while if the value is nonzero it enables the feature. 


The IUSC loads the value from the TCLR into the 
Transmit Character Counter, and enables or disables 
the TCC accordingly, when one of the following 
occurs: 


1. software writes the Trigger Tx DMA (or Trigger Tx 
and Rx DMA) command to the RTCmd field of the 
Channel Command/Address Register (CCAR15- 
11), 

2. software writes the Load TCC (or Load RCC and 
TCC) command to RTCmd in the CCAR, 

3. software writes the Purge Tx FIFO (or Purge Tx 
and Rx FIFO) command to RTCmd in CCAR, or 

4. the TxCtriBlk field in the Channel Control Register 
(CCR15-14) is 10, specifying a two-word Transmit 
Control Block, and the Transmit DMA channel 
fetches (the second byte of) the second word con- 
taining the new character count. Which is to say, 
the IUSC fetches the count "through" the TCLR. 


The IUSC loads the value from the RCLR into the 
Receive Character Counter, and enables or disables 
the RCC feature, when any of the following occur: 


1. software writes the Trigger Rx DMA (or Trigger Tx 
and Rx DMA) command to the RTCmd field of the 
Channel Command/Address Register (CCAR15- 
11), 

2. software writes the Load RCC (or Load RCC and 
TCC) command to RTCmd in the CCAR, 


3. software writes the Purge Rx FIFO (or Purge Tx 
and Rx FIFO) command to RTCmd in CCAR, or 


4. the Receiver detects an opening Flag or Sync 
character. 


Once the IUSC has loaded the TCC or RCC with a 
non-zero value (which enables the feature) it 
decrements the counter for each character/byte 
written into the associated FIFO. That is, the Trans- 
mitter decrements the TCC by 1 or 2 when software or 
the Transmit DMA channel loads transmit data into the 
TxFIFO. The Receiver decrements the RCC by 1 for 
each character/byte that it transfers from its shift 
register into the RxFIFO. 


A non-zero TCLR value should represent the number 
of characters to send (of course this doesn't include 
any Transmit Control Block information). A non-zero 
RCLR value can be either all ones, or the maximum 
number of characters/bytes allowed in a message or 
frame, including any CRC (not including any Receive 
Status Block information). For applications like 1553B, 
the RCLR value should simply be the number of char- 
acters/bytes between successive RSB's. For frame or 
message-oriented applications in which there's no 
particular maximum received frame or message 
length, the all-ones value simplifies computing the 
length of each frame or message slightly. This value 


allows software to obtain the frame length by simply 
ones-complementing the value read from RCCR or 
from a Received Status Block in memory, rather than 
by subtracting it from the starting value. 


On the Transmit side, software can read the value in 
the TCC at any time from the Transmit Character 
Count Register (TCCR), but writing the TCCR address 
has no effect. Figure 45 shows a decoder that detects 
when the counter contains 0001. When software or 
the Transmit DMA channel writes enough data into the 
TxFIFO so that the TCC counts down to 0, the IUSC 
marks the character that corresponds to decrementing 
from 1 to 0 as End of Frame / End of Message 
(EOF/EOM). When this character gets to the other 
end of the FIFO, the marking makes the Transmitter 
conclude the frame appropriately. (Typically, it sends 
a CRC and a closing Flag or Sync character after the 
marked character.) 


If software or the Transmit DMA channel writes 16 bits 
to the TDR while the TCC contains 0001, the serial 
controller only puts the character on the IUSC's 
internal D7-0 lines into the TxFIFO -- it ignores the 
data on the internal D15-8 lines. In a system in which 
even-addressed bytes fall on D7-0 (e.g., a system 
based on a Zilog Z380 or an Intel processor) this isn't 
a problem. On the other hand, in systems in which 
even-addressed bytes reside on D15-8 (e.g., a system 
based on a Zilog Z8000 or 16COx or a Motorola 
680x0) it can cause problems. 


Non-Zero 
Detect 


Chapter 5 describes a feature of the 16C32's Tx DMA 
channel that helps alleviate this problem. If the Tx 
DMA channel is reading the data in a frame 16 bits at 
a time, and it decrements its Transmit Byte Count 
Register (TBCR) to 1, it next signals the memory for a 
byte read, and ensures that the data from the proper 
half of the data bus (according to "Select D15-8 First" 
or "Select D7-0 First" commands) is driven onto the 
internal D7-0 lines for the serial controller. 


Assuming that 
1. the Tx DMA channel is used, 


2 the end of a transmitted frame always corres- 
ponds to the end of a memory buffer, and 
3. the TBCR is programmed to reflect the number of 
transmit characters in the buffer, rather than 
relying on the Early Termination feature to 
terminate the buffer, 
then this feature eliminates an unfortunate require- 
ment that previous USC family members imposed on 
host software in Big Endian systems. This require- 
ment still applies when these assumptions aren't met: 
if the last character of a frame falls at an even address 
in a Big Endian system, software must copy the last 
character into the subsequent odd address as well, 
before presenting the frame to the Tx DMA channel. 


f LO 
a py Counter (TCCR) 
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Figure 45. A Model of the Transmit Character Counter Feature 
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Figure 46. A Model of the Receive Character Counter Feature 


The Transmitter suppresses its DMA request from the 
time the Transmit DMA channel places the EOF/EOM 
character in the TxFIFO until the Transmitter sends it. 
When software uses the Transmit Control Block 
feature, this procedure ensures that the Transmit DMA 
channel doesn't load the control information for the 
next frame or message, while the Transmitter still 
needs the values for the current one. 


On the Receive side, software can't directly read the 
RCC (except perhaps by using test modes that are 
beyond the scope of this section). Instead, when the 
Receiver detects an end-of-frame situation, it captures 
the decremented value in the counter into a four-entry 
RCC FIFO and in a register called RCHR. (It may do 
this when it receives a Flag or Sync character, or, in 
External Syne and 802.3 modes only, when the /DCD 
pin goes false.) It then reloads the RCC from RCLR in 
preparation for the next frame. If software enables 
two-word Receive Status Blocks, the IUSC stores the 
value from RCHR as the second word of the RSB. 


Besides recording the length of received frames/ 
messages, the RCC feature can help detect frames or 
messages that are longer than a maximum length 
defined by the serial protocol. This typically happens 
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because the Flag, terminating character or Sync 
character(s) separating two frames or messages gets 
corrupted on the serial link. This makes the two 
frames or messages look like a single continuous one 
to the Receiver. The usual strategy in such a case is 
to ignore (or possibly "NAK") the whole mess. 


If the |IUSC decrements the RCC to zero and then 
receives another character as part of the same frame/ 
message, it sets the RCCUnder L/U bit in the Miscel- 
laneous Interrupt Status Register (MISR3). To use 
this feature to check for overly long frames or mes- 
sages, program the RCLR with the maximum number 
of characters that a frame or message can validly 
have. This value should include any terminating and 
CRC characters but exclude any Receive Status Block 
information. Also, arm the RCC Underflow interrupt by 
setting the RCCUnder IA bit in the Status Interrupt 
Control Register (SICR3), as described in Chapter 6. 


If the IUSC ever sets RCCUnder L/U and interrupts, 
clear the condition by writing a 1 to the L/U bit, discard 
the data received for the frame(s) by purging the 
RxFIFO, reprogram the Receive DMA channel if it's 
being used, and do whatever else is necessary to 
clean up the situation. Then write the "Enter Hunt 


Mode" command to the RCmd field of the Receive 
Command/Status Register (RCSR15-12). 


The RCC FIFO 


Figure 46 shows the RCC FIFO. When software has 
enabled the Receive Character Counter, the FIFO 
captures the contents of the RCC at the end of each 
frame or message in External Sync, Transparent Bi- 
sync, 802.3, and HDLC/SDLC modes. (The previous 
section described how the Receiver decrements the 
RCC by one for each character it receives.) 


The RCC FIFO can hold up to four 16-bit entries. 
Figure 47 shows the Channel Command/Status Regi- 
ster (CCSR), the 3 MSBits of which allow software to 
monitor and control the RCC FIFO. The RCCFAvail 
bit (CCSR14) is 1 if the RCC FIFO contains at least 
one entry, or is 0 if the RCC FIFO is empty. 


When RCCFAvail is 1, software can read the oldest 
entry in the RCC FIFO from the Receive Character 
Count Register (RCCR). It can then compute the 
length of the frame or message by subtracting this 
ending value from the starting value that came from 
the Receive Count Limit Register (RCLR). (Or, if the 
starting value was all ones, software can simply one's 
complement the value from RCCR.) Reading the 
RCCR removes the oldest entry from the RCC FIFO. 


For internal synchronization reasons a 16C32 doesn't 
set RCCFAvail, nor certain other status related to an 
End of Frame condition, until one bit time after it 
places an RxBound character in the RxFIFO. Unlike 
the 16C31, the 16C32 delays forcing an Rx Data 
interrupt and/or an Rx DMA request until the same 
RxCLK rising edge at which it sets RCCFAvail, so that 
an Rx Data service routine can rely on the RCC FIFO 
and its status flags being current. 


lf software has enabled the RCC, and a frame or mes- 
sage ends when the RCC FIFO is already full, the new 
value overwrites its predecessor, and the three oldest 
entries are not affected. The |USC remembers this 
event in a status bit that it routes through the RCC 
FIFO (much like it routes other status bits through the 
RxFIFO). When software reads the preceding entries 
so that an overwriting/overwritten entry becomes the 
oldest one left in the RCC FIFO, the IUSC sets the 
RCCFOvilo bit in the Channel Command / Status 
Register (CCSR15). Once RCCFOviilo is set, the only 
way to clear it (other than to Reset the whole serial 
controller) is to write a 1 to the ClearRCCF bit 
(CCSR13). This also empties the RCC FIFO and 
clears the RCCFAvail bit. 


Writing to the RCCFOvflo and RCCFAvail bits has no 
effect, nor does writing a 0 to the ClearRCCF bit. 
ClearRCCF always reads as 0. 
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Transmit Control Blocks® 


Figure 48 shows the Channel Control Register. Its 
TxCtriBik field (CCR15-14) controls what the Trans- 
mitter does with the first 16 or 32 bits of data that the 
Transmit DMA channel or software writes to the TDR 
at the start of a frame or message. (While software 
can use Transmit Control Blocks when it fills the 
TxFIFO, there's no obvious reason to do so, 
compared to just writing the control registers directly.) 
The Transmitter interprets TxCtriBlk as follows: 
TxCtrlBlk Kind of TCB's used 

00 No Transmit Control Block 

01 16-bit Transmit Control Block 

10 32-bit Transmit Control Block 

11 Reserved; do not program 


When TxCtriBlk is 01 or 10, the IUSC treats the next 
16 or 32 bits, that the Transmit DMA channel or 
software writes to the TDR, as a Transmit Control 
Block after any of following happen: 

1. after software writes the Trigger Tx DMA (or Trig- 
ger Tx and Rx DMA) command to the RTCmd field 
of the Channel Command / Address Register 
(CCAR15-11), 


2. after software writes the Load TCC (or Load RCC 
and TCC) command to RTCmd, 

3. after software writes the Purge Tx FIFO (or Purge 
Tx and Rx FIFO) command to RTCmd, or 

4. after the Transmit DMA channel (or software) 


writes data into the TxFIFO that decrements the 
TCC to zero. As noted in an earlier subsection, 
the Transmitter drops its DMA request from the 
time the DMA channel fetches the last character of 
a frame, until after it transfers the character to its 
serial shift register. It does this so that the DMA 
channel doesn't fetch the Transmit Control Block 
for the next frame or message, while the Trans- 
mitter still needs the control information for the 
current frame. 


Chapter 5 describes how the 16C32's Transmit DMA 
channel can fetch a Transmit Control Block from either 
of two locations in memory. The first method is 
16C31-compatible: the channel fetches the TCB from 
the memory data buffer, before fetching the first 
characters of the frame or message. The other 
method is new with the 16C32, and applies only when 
the Tx DMA channel is in "Array mode" or "Linked List 
mode". With this method, the channel fetches a TCB 
from the Array or Linked List entry for a buffer other 
than the first one in the list, if its start aligns with the 
start of a frame. For the transmit side the choice 
between these methods should be based on which is a 
better fit with the software I/O architecture. 


6 Previous USC documentation called these Transmit Status Blocks. 
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Figure 48. The Channel Control Register (CCR) 


TxSubMode Reserved (0) TxResidue Reserved (0) 
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Figure 49. The First (or Only) 16 bits of a Transmit Control Block 

















Figure 49 shows the format of the first word of a 32-bit | Recelve Status Blocks 


TCB or the only word of a 16-bit TCB. Its most ; a7 
eae The Receiver sets the RxBound bit in the RxFIFO to 
significant four bits define a new TxSubMode value for indicate the end of a frame, message, or word, in 


the following transmit data. When the Transmit DMA External Sync, Transparent Bisync, 802.3, HDLC/ 


channel or software writes this word to the TDR, the 
re oe SDLC, and ACV/1553B modes. In these modes the 
IUSC copies these four bits into the TxSubMode field Receiver can store summary/status information in 


of its Channel Mode Register (CMR15-12) without 
memory for each frame, message, or 1553B word. 
changing the rest of the CMR. Bits 4-2, of the first or The RxStatBik field of the Channel Control Register 


only word, define the TxResidue value for the following 
at (CCR7-6) controls whether it does this. The IUSC 
frame in HDLC/ SDLC or HDLC/SDLC Loop mode. interprets it like TxCtriBlk: 


The IUSC_ similarly copies these bits into the . 

TxResidue field of the Channel Command/Status RxstatBik Kind_of RSB_s_used 

Register (CCSR4-2) without affecting the rest of the OC ANG Scene et eces eres 
CCSR. The device ignores bits 11-5 and 1-0 of the O12 6- Bee Ree ye eeecue eOck 
first or only word of a TCB, but Zilog reserves these Bie pibcuriaty wcmrliaipauna aces: 
bits for future enhancements and software should 11 Reserved; do not program 
ensure that they're all zero. If this field is either 01 or 10, the Receiver stores 
frame status as the first word of a 32-bit Receive 


should contain the number of characters/bytes in this Status Block, or the only word ofa 16-bit RSB. Figure 
frame or message. The IUSC writes this word through 50 shows this word, which is similar to but not identical 
the Transmit Count Limit Register (TCLR) and into the we the eee sti Receive rica Status 
Transmit Character Counter (TCCR). In a non-block- agister ( ). The di ete? ee a 

structured mode like 1553B, the value simply reflects 1. The IUSC forces the bits that correspond to 


For most protocols, the second word of a 32-bit TCB 


the number of bytes until the next TCB. Note that with ExitedHunt, IdleRcved, and Break/Abort in the 
a 16-bit TCB, the IUSC still reloads the TCC, but it RCCR to 0. These are "global" rather than 
uses the old value in TCLR to do so. Thus, 16-bit "queued" status bits, and must be handled by 
TCBs are useful in protocols that use fixed-length Software on a more or less real-time basis. 
frames or messages, but 32-bit TCBs should be used 2. The LSBit of the first word of an RSB is a copy of 
when successive transmitted frames or messages can the LSBit of the RCC at the end of the frame, 
vary in length. rather than the RxAvail bit that's in the RCCR. 

; This bit is also available in the RCC FIFO and in 
Chapter 5 describes and shows the various cases of the second word of a 32-bit RSB, but for 16-bit 


TCB placement in memory in DMA applications. DMA operation it may be handy to have it here, 


especially in a 16-bit RSB. 


ShortF/ Always} CRCE | Abort |} Rx 


RxResidue CVType 1 IFE /PE | Over 


15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Figure 50. The First (or Only) 16 Bits of a Receive Status Block 
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The CRCE/FE bit in an RSB reflects the CRC- 
correctness of the frame in 802.3 and HDLC/SDLC 
modes, but not in Transparent Bisync mode. 


A 10 in RxStatBlk makes the IUSC also store the 
ending value of the Receive Character Counter in a 
second 16-bit word after the frame status word. 


Chapter 5 describes how the Receive DMA channel 
can store an Receive Status Block in memory in two 
different ways. With the 16C31-compatible method, 
the DMA channel does not handle the RSB in any 
special way, it simply stores it in the memory buffer 
after the RxBound character, and decrements its 
Receive Byte Count Register (RBCR) as for serial 
data. 


The other method is new with the 16C32, and more or 

less assumes the following circumstances: 

1. the Receive DMA channel is in Array or Linked 
List mode, and either 


2A. the channel's Early Termination feature is enabled, 
or 

2B the line protocol uses a fixed frame length and 
memory buffers are of this length as well, 


When this method, after a buffer is terminated the 
Receive DMA channel reads the RSB and stores it in 
the Array or List entry for the terminated buffer, before 
going on to the next one. The channel does not 
decrement its byte count as it transfers this data. 


The problem with the 16C31-compatible method is 
that software has to know how long each received 
frame is, in order to find its RSB. To obtain these 
lengths it has to read the RCC FIFO in a sufficiently 
timely manner to prevent overflows. For four or more 
successive frames each composed of, say, 4-6 char- 
acters, the four-entry depth of the RCC FIFO may 
impose interrupt-response requirements that can't be 
met in the worst-case. 


By contrast, storing the RSB's in Array or Linked List 
entries allows software to ignore the receive process 
for longer periods, these being limited only by the 
extent of the Array or List structures it sets up, and/or 
by response timeouts imposed by the serial protocol. 


When software or the Receive DMA channel reads 16 
bits from the RDR, and the Receiver has marked the 
oldest character in the RxFIFO with RxBound status, 
the IUSC only takes that one character out of the 
RxFIFO. When the Receive DMA channel is doing 
16-bit transfers, software has several ways to figure 
out whether the 16-bit "word" preceding a RSB 
contains one or two characters/bytes. 


The most straightforward way is to compute the length 
of the frame or message, by subtracting the ending 
RCC value in the RCC FIFO or the second word of the 
RSB, from the starting RCC value that the hardware 


70 


took from RCLR. (If the starting value was all ones, 
software can just ones-complement the ending value.) 
If the result is odd there's one character in the 16-bit 
word that precedes the RSB, while if it's even there 
are two characters in the word. 


A "narrower" version of the same computation is that if 
bit O of the first or second word of the RSB is the 
same as the units bit of the starting RCC value that 
came from RCLR, then the preceding word contains 
two characters. If the two bits are different the word 
contains only one character. 


Still another method applies only when bits 2-1 of the 
first word of the RSB, namely Abort/PE and RxOver, 
are both 0. The usual handling for a receive overrun 
condition in synchronous modes includes forcing the 
receiver into Hunt mode for the start of the next frame 
or message, which means that an RSB would never 
be stored for a frame that encountered an overrun. 
When Abort/PE and RxOver are both zero, if bit 14 of 
the first word of the RSB (1stBE) is 1, there is one 
character in the preceding word, while if bit 14 is 0 
there are two characters. 


Chapter 5 describes the various ways in which the 
Receive DMA channel can store an RSB in memory. 


Using TCB's and RSB's In ACV (1553B) Mode 


In Asyne with Code Violations (1553B) mode, the. 
Receiver sets the RxBound bit for the second (or only) 
byte of each word received. It does this so that soft- 
ware can use the Receive Status Block mechanism to 
record the type of Code Violation (Command/Status or 
Data) that introduced each word. To use this facility, 
software should program the RxStatBlk field (CCR7-6) 
to 01 to select 16-bit RSB's. The Receiver then stores 
a 16-bit status word after each word (or byte) of 
received data. The ShortF/ CVType bit (bit 8) of the 
status word is 1 after a "command/status" word and 0 
after a "data" word. 


On the Transmit side, software can use Transmit 
Control Blocks to send any sequence of mixed Com- 
mand/Status and Data words under DMA control. To 
do this, it should program TxCtriBIk (CCR15-14) to 10 
to select 32-bit TCB's, and should structure the data in 
memory so that a TCB precedes each block of words 
of the same kind. Bit 12 of the first word of each TCB 
(the LSBit of the TxSubMode value) should be 1 for a 
block of Command/Status words and 0 for a block of 
Data words. The second word of each TCB should 
specify the number of bytes in the block (typically this 
is twice the number of words). 


RT Chan 
10 9 8 7 6 


15 14 13 12 11 5 4 3 2 1 0 
Figure 51. The Channel Command/Address Register (CCAR) 


Commands 10101 Select Serial MSBit First 
; 10110 Select D15-8 First 

Commands are encoded values that software writes to MOLT. Select“pia0- Piet 

a register field to change the state of the IUSC or 

make it perform some action. Typically commands TCmd 

don't take any software-perceptible time to perform. Value Function 

IUSC command fields are write-only; reading them 0010 Clear Tx CRC Generator 

back may yield zeroes, or some unrelated status item. sae ey coe natn ee 
elec i= atus 

Often commands represent a more compact and effi- 0110 Select TICRHi=/INT Level 

cient way to provide control features than dedicated 0111 Select TICRHi=/TxREQ Level 

register bits. In fact, commands are so popular that 1000 Send Frame/Message 

the IUSC includes three separate encoded command 1001 Send Abort 

fields in its serial section and one in its DMA section! 1100 Enable DLE Insertion 

Figure 51 shows the Channel Command / Address 1101 Disable DLE Insertion 

Register. Software can write any of 18 different 1110 Clear EOF/EOM 

commands that affect the Transmitter and/or the 1111 Set EOF/EOM 

Receiver to its RTCmd field (CCAR15-11). = In ae 

addition, software can write any of 11 commands that ; 

affect the Transmitter to the TCmd field in the Tanta Gace ee ee : 

Transmit Command/Status Register (TCSR15-12). 014 eer a ca 

Finally, software can write any of six commands that Bee. mcer- Hone Doce 

affect the Receiver to the RCmd field in the Receive 0100 Select RICRHI=RTSA Data 

Command/Status Register (RCSR15-12). Chapter 5 Civ ir erect RICRH STE EO ee ecue 

describes the commands for the IUSC's DMA chan- O110 Select: RICRHi=/INT Level 

0111 Select RICRHi=/RxREQ Level 


nels that software can write to the DMA Command / 
Address Register. 


Writing all zeroes to any of the command fields 
does nothing, which can be useful when the intent is 
to write to other fields of the register. Zilog reserves 
other values not listed below for future extensions to 
the USC family; such values should not be written to 
the subject field. 


RTCmd 

Value Function 

00010 Reset’ Highest Serial IUS 
00100 Trigger Channel Load DMA 
00101 Trigger Rx DMA 

00110 Trigger Tx DMA 

00111 Trigger Rx and Tx DMA 
01001 Purge Rx FIFO 

01010 Purge Tx FIFO 

01011 Purge Rx and Tx FIFO 
01101 Load RCC 

01110 Load TCC 

01111 Load RCC and TCC 

10001 Load TCO 

10010 Load TCl 

10011 Load TCO and TCl 

10100 Select Serial LSBit First 
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A description of each command follows, in alphabetical 
order. Some of them include references to other 
chapters or sections, which provide more information 
that's important to fully understanding the command. 


Clear EOF/EOM (TCmd:=1110): this command con- 
ditions the IUSC so that it doesn't mark the next char- 
acter, that software or the Transmit DMA channel 
writes to the Transmit Data Register, as End of 
Frame/End of Message. Since the IUSC assumes this 
state after each write to the TDR, and after a hardware 
or programmed Reset, software will need this 
command only if it "changes its mind" about where the 
frame ends, between issuing a Set EOF/EOM 
command and writing the TDR. 


Clear Rx or Tx CRC Generator’? (RCmd or TCmd:= 
0010): these commands force the Receive or Transmit 
CRC Generator to all zeroes or all ones, depending on 
the RxCRCStart bit in the Receive Mode Register 
(RMR10) or the TxCRCStart bit in the Transmit Mode 
Register (TMR10). Software will seldom need these 
commands because the Receiver and Transmitter 


7 Previous USC documentation called these commands Preset CRC 


automatically clear their associated CRC generators at 
the start of each frame. 


Disable DLE Insertion (TCmd:=1101): this command 
applies only to Transparent Bisyne mode. It conditions 
the IUSC so that it doesn't check subsequent 
characters written to the Transmit Data Register 
(TDR) for DLE characters, and so that it doesn't add 
any DLE characters to the transmitted data stream. 
Software should use this command before writing a 
two-character control sequence that starts with DLE to 
the TDR. DLE insertion remains disabled until soft- 
ware issues the Enable DLE Insertion command or 
until a hardware or software Reset. The IUSC queues 
the state that's affected by this and the following 
command through its TxFIFO with each character, so 
that software can change the state as needed. 


Enable DLE Insertion (TCmd:=1100): this command 
applies only to Transparent Bisync mode. It conditions 
the IUSC so that it checks subsequent characters 
written to the Transmit Data Register (TOR) for DLE 
characters, and adds another DLE for each DLE 
written to the TDR. Software should use this 
command before writing normal data to the TDR. DLE 
insertion remains enabled until software issues the 
Disable DLE Insertion command. The IUSC queues 
the state that's affected by this and the preceding 
command through its TxFIFO with each character, so 
that software can change it as needed. 


Enter Hunt Mode (RCmd:=0011): this command 
forces the Receiver into "Hunt Mode" immediately, 
regardless of its previous state. In synchronous 
modes, this means that the Receiver starts searching 
for a Sync or Flag sequence. In asynchronous modes 
it starts searching for a start bit or (in 1553B mode) for 
a code violation. In any mode, the Receiver discards 
any partial character that was in progress when 
software issued the command. 


Load RCC and/or TCC® (RTCmd:=01101-01111): 
these commands load the Receive and/or Transmit 
Character Counter from the Receive and/or Transmit 
Count Limit Register (RCC from RCLR and/or TCC 
from TCLR). This may enable or disable character 
counting. If software has enabled the Transmit Con- 
trol Block feature in the TxCtriBlk field of the Channel 
Control Register (CCR15-14=01 or 10), a Load TCC or 
Load RCC and TCC command also conditions the 
Transmitter to treat the next data written to the 
Transmit Data Register as a TCB. 


Load TCO and/or TC1 (RTCmd:=10001-10011): 
these commands load the counter in Baud Rate 
Generator 0 and/or 1 from the Time Constant 0 and/or 
1 Register (BRGO from TCOR and/or BRG1 from 


8 Previous USC documentation called these commands Reload TCC and/or RCC 


TC1R). Loading a BRG via one of these commands 
also enables it to count. This is particularly important 
when software has programmed a BRG for single 
cycle mode (HCR1=1 for BRGO or HCR5=1 for BRG1) 
and it has stopped after counting down to zero. See 
Chapter 3 for more information about the BRG's. 


Purge Rx and/or Tx FIFO (RTCmd:=01001-0101 1): 
these commands remove ail entries from the RxFIFO 
and/or TxFIFO. These commands also reload the 
Receive and/or Transmit Character Counter from the 
Receive and/or Transmit Count Limit Register (RCC 
from RCLR and/or TCC from TCLR). This may enable 
or disable character counting. If software has enabled 
the Transmit Control Block feature in the TxCtriBlk 
field of the Channel Control Register (CCR15-14=01 
or 10), a Purge Tx FIFO command also conditions the 
Transmitter to treat the next data written to the 
Transmit Data Register as a TCB. If software is using 
the Transmit DMA channel, a Purge Tx FIFO 
command may cause the /TXREQ pin to be asserted 
immediately, while if it's using Transmit Data 
interrupts, the command may cause the /INTA or 
/INTB pin to be asserted immediately. (The previous 
two sentences also apply to a Purge Rx and Tx FIFO 
command.) 


Reset Highest Serial IUS (RTCmd:=00010): Chapter 
6 describes how this command clears the highest- 
priority Interrupt Under Service latch in the serial 
controller section that's currently set (if any). 


Select D15-8 or D7-0 First? (RTCmd:=10110-10111): 
these commands control which of the two characters 
in a 16-bit write to the TDR/TxFIFO the Transmitter 
sends first. They also control how the IUSC arranges 
the oldest and second-oldest characters in the 
RxFIFO when software or the Receive DMA channel 
reads 16 bits from it via the Receive Data Register. 
"D15-8 First" is the default value after either a hard- 
ware or programmed reset, and is compatible with the 
Zilog Z8000, Zilog 16COx and Motorola 680x0 proces- 
sors. "D7-0 First" should be programmed for the Zilog 
Z380 and most Intel processors. The IUSC applies 
this option only during a 16-bit transfer, between the 
TxFIFO or RxFIFO and the AD15-0 pins. However, if 
the Transmit Character Counter contains 0001 and the 
Transmit DMA channel writes 16 bits to the TxFIFO, 
the IUSC only puts the character from AD7-0 in the 
TxFIFO, regardless of these commands. In a "D7-0 
First" system this isn't a problem. But if the last 
character of a frame or message falls at an even 
address when using the Transmit DMA channel in a 
"D15-8 First" system, software must copy the last 


3 Previous USC documentation called these commands Select Straight Memory 
Data and Select Swapped Memory Data. 
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character into the subsequent odd address as well. 
(Usually this applies to a frame with an odd length.) 


Select RICRHi=/INT Level (RCmd:=0110): this 
command conditions the IUSC so that subsequent 
accesses to the MSByte of the Receive Interrupt 
Control Register (RICR15-8) read or write the number 
of received characters at which the IUSC starts 
requesting a Receive Data interrupt, as described in 
Chapter 6. If software uses the Receive DMA channel 
to store data in memory, it should disable Receive 
Data interrupts. 


Select RICRHi=/RxREQ Level (RCmd:=0111): this 
command conditions the !USC so that subsequent 
accesses to the MSByte of the Receive Interrupt 
Control Register (RICR15-8) read or write the number 
of received characters at which the Receiver asserts 
/RxREQ to the Receive DMA channel, as described in 
Chapter 5. 


Select RICRHi=FIFO Status (RCmd:=0101): this 
command conditions the I|USC so that reading the 
MSByte of the Receive Interrupt Control Register 
(RICR15-8 yields the number of characters in its 
RxFIFO. This is described more fully in The Data 
Registers and the FIFOs later in this chapter. 


Select RICRHI=RTSA Data (RCmd:=0100): this 
command conditions the IUSC so that subsequent 
accesses to the MSByte of the Receive Interrupt 
Control Register (RICR15-8) read or write Receive 
Time Slot Assigner data. This is described more fully 
in Programming the Time Slot Assigners in Chapter 3. 


Select Serial Data LSB or MSB First (RTCmd:= 
10100-10101): these commands control whether the 
IUSC transmits and assembles serial data with the 
Least Significant or Most Significant bit going first on 
the line. "LSB first" is the default after either a 
hardware or programmed reset, and is the method 
used in most traditional data communications 
schemes. The IUSC applies this option as it transfers 
data between the AD pins and the FIFOs. Because of 
this, these commands don't affect functions like 
matching addresses and sync characters and sending 
syncs. This, in turn, means that software must 
program such values "backward" in the TSR and RSR 
for "MSB first" applications. 


Select TICRHi=/INT Level (TCmd:=0110): this 
command conditions the IUSC so that subsequent 
accesses to the MSByte of its Transmit Interrupt 
Control Register (TICR15-8) read or write the number 
of empty TxFIFO entries at which the Transmitter 
starts requesting a Transmit Data interrupt, as 
described in Chapter 6. If software uses the Transmit 
DMA channel to fetch data from memory, it should 
disable Transmit Data interrupts. 
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Select TICRHi=/TxREQ Level (TCmd:=0111): this 
command conditions the IUSC so that subsequent 
accesses to the MSByte of the Transmit Interrupt 
Control Register (RICR15-8) read or write the number 
of empty TxFIFO entries at which the Transmitter 
asserts /TXREQ to the Transmit DMA channel, as 
described in Chapter 5. 


Select TICRHi=FIFO Status (TCmd:=0101): this 
command conditions the IUSC so that reading the 
MSByte of the Transmit Interrupt Control Register 
(TICR15-8) yields the number of empty entries in its 
TxFIFO. This is described more fully in The Data 
Registers and the FIFOs later in this chapter. 


Select TICRHi=TTSA Data (TCmd:=0100): this 
command conditions the IUSC so that subsequent 
accesses to the MSByte of the Transmit Interrupt 
Control Register (TICR15-8) read or write Transmit 
Time Slot Assigner data. This is described more fully 
in Programming the Time Slot Assigners in Chapter 3. 


Send Abort (TCmd:=1001): this command is valid 
only in HDLC/SDLC mode and makes the Transmitter 
send an Abort (Go Ahead) sequence. If the 2 MSBits 
of the TxSubMode field of the Channel Mode Register 
(CMR15-14) are 01, the Abort consists of a zero fol- 
lowed by 15 consecutive ones. Otherwise it consists 
of a zero followed by seven ones. After sending the 
Abort, the Transmitter operates as it would have after 
sending a closing Flag. That is, if Wait2Send (TICR2) 
is O and there's data in the TxFIFO, it starts a new 
frame, otherwise it sends the Idle condition defined by 
the Txldle field (TCSR10-8). 


Send Frame/Message (TCmd:=1000): if the 
Wait2Send bit in the Transmit Interrupt Control 
Register (TICR2) is 1, the Transmitter waits between 
frames, sending the Idle pattern defined by the Txldle 
field of the Transmit Command/Status Register 
(TCSR10-8), until software issues this command. The 
later section Synchronizing Frames/Messages with 
Software Response describes how this feature differs 
from the one controlled by the Wait4TxTrig bit in the 
Channel Control Register and the Trigger Tx DMA 
command in RTCmd. 


Set EOF/EOM (TCmd:=1111): this command condi- 
tions the IUSC so that it marks the next character that 
software or the Transmit DMA channel writes to the 
Transmit Data Register (TDR) as End of Frame/End of 
Message. This marking makes the Transmitter 
perform the appropriate closing actions after sending 
the character. (For example, in HDLC/SDLC mode it 
sends a CRC and then aclosing Flag.) Typically, after 
issuing this command, software should write the last 
character of the frame or message to the LSByte of 
the Transmit Data Register (TDR7-0). The I|USC auto- 
matically clears the state set by this command when 
software (or the Transmit DMA channel) writes to the 


TDR. Therefore this command applies to at most one 
character. 


Trigger Channel Load DMA (RTCmd:=00100): 
Chapter 7 will describe how this command puts the 
serial controller section of the IUSC in a special mode 
in which the Transmit DMA channel can initialize all 
the registers in the serial controller. Software must 
program and set up the Transmit DMA channel as for 
transmitting data, before it issues this command. This 
operation can't initialize any of the registers in the 
I|USC's DMA section. 


Trigger Rx and/or Tx DMA (RTCmd:=00101-0011 1): 
if one of the Wait4xxTrig bits in the Channel Control 
Register (CCR13 for Tx, CCR5 for Rx) is 1, the serial 
controller section of the IUSC stops requesting that 
kind of DMA transfer after the end of each frame. 
When this happens, software should use one of these 
commands to reenable requests to one or both DMA 
channel(s), for the next frame. These commands also 
load the Receive and/or Transmit Character Counter 
from the Receive and/or Transmit Count Limit Register 
(RCC from RCLR and/or TCC from TCLR). This may 
enable or disable character counting. If software has 
enabled the Transmit Control Block feature in the 
TxCtriBlk field of the Channel Control Register 
(CCR15-14=01 or 10), a Trigger Tx DMA or Trigger Tx 
and Rx DMA command also conditions the Transmitter 
to treat the next 16 or 32 bits written to the Transmit 
Data Register as a TCB. The later section 
Synchronizing Frames/Messages with Software 
Response describes how this feature differs from the 
one controlled by the Wait2Send bit in the Transmit 
Interrupt Control Register and the "Send 
Frame/Message" command in TCmd. 


Resetting the Serial Controller 

Figure 51 shows the RTReset bit in the Channel 
Command/Address Register (CCAR10). Software can 
use this bit to reset the serial controller section of the 
IUSC to a known and inactive state like that produced 
by driving the /RESET pin low. (The most significant 
difference is that the IUSC requires software to write 
the Bus Configuration Register (BCR) after a hardware 
reset, but not after this kind of "software Reset".) 


To software-reset the serial controller when using a 
16-bit data bus: 

1, Write CCAR (or its MSByte) with RTReset=1. 

2. Write a 16-bit zero to CCAR. 

To software-reset the serial controller when using an 
8-bit bus: 

1. Write the MSByte of CCAR with RTReset=1. 

2. Write the LSByte of CCAR with an 8-bit zero. 

3. Write the MSByte of CCAR with an 8-bit zero. 
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The way this "software reset" works is that the 1 state 
of RTReset conditions the serial controller's register 
address decoding logic so that the subsequent write 
operation actually writes data into all the registers in 
the serial controller. Between the time that software 
writes RTReset as 1, and when it writes it back to 0, 
the IUSC doesn't drive I/O pins, it either 3-states 
output pins or holds them in their inactive state, but 
register bits that don't directly affect these pins are 
unchanged/undefined. 


Leaving the RTReset bit set is a common mistake 
made by first-time users of a USC family member. 


The Data Registers and the FIFOs 


When the RxFIFO contains received characters, soft- 
ware can read the "oldest" 1 or 2 characters in it from 
the Receive Data Register (RDR). When software 
uses the Receive DMA channel, it takes care of taking 
data out of the RxFIFO, in a "flyby" fashion using an 
internal "RxACK" signal. The Mode Registers: Char- 
acter Length, earlier in this Chapter, describes how the 
Receiver aligns characters and fills out bytes in the 
RDR/RxFIFO when characters are less than 8 bits 
long. 


Similarly, when the TxFIFO isn't full software can write 
1 or 2 characters to it via the Transmit Data Register 
(TDR), or the Transmit DMA channel can write the 
TxFIFO in a flyby fashion using an internal "TxACK" 
signal. 


Chapter 2 describes how software can access the 
TDR and RDR using a register address that may be 1) 
multiplexed on the AD5-1 pins, 2) full-time on AD13-8 
if only AD7-0 carry data, or 3) written into the Channel 
Command / Address Register (CCARS5-1). 


Two other features of the IUSC make it easier for 
software to access these registers when the AD lines 
don't carry multiplexed addresses and the data bus is 
16 bits wide. Host processor write cycles to the IUSC, 
with the S//D and D//C pin both high, always write the 
TDR. Similarly, host processor read cycles from the 
IUSC, with S//D and D//C both high, always read the 
RDR. Typically the system designer connects these 
pins to processor address lines, such as A2 and Ai for 
a non-multiplexed 16-bit bus, or A8 and A7 for a 
multiplexed bus. 


Chapter 2 also describes how to write the Bus Config- 
uration Register to configure the IUSC for a 16-bit data 
bus. With a 16-bit data bus, software can write two 
characters at once to the TDR, or the Transmit DMA 
channel can read two characters out of memory at 
once. Similarly, software can read two characters at a 
time from the RDR, or the Receive DMA channel can 
write two characters into memory in each bus cycle. 
The earlier section Commands describes how the 
"Select D15-8 First" and "Select D7-0 First" com- 


mands allow the two characters, in each 16-bit transfer 
to the TDR or from the RDR, to be arranged in either 
order. This is important because available micro- 
processors differ about the order. 


With a 16-bit data bus, software can read or write 
most IUSC registers as a 16-bit word, or can read or 
write either their "more significant" byte (bits 15-8) or 
"less significant" byte (bits 7-0). The TDR and RDR 
are different in this regard: software should never read 
or write their more significant bytes alone, only as part 
of a 16-bit transfer. On a Zilog Z8000 or 16COx or 
Motorola 680x0 based system this typically means that 
software should write bytes to the TDR and read bytes 
from the RDR at odd addresses. On a Zilog Z380 or 
Intel 80x86 processor, software should typically write 
bytes to the TDR and read bytes from the RDR at 
even addresses. 


On a 16-bit bus there's no way for software to read 
single characters from RDR, or write single characters 
to TDR, using an address that makes D//C high. To 
do this, software must either address the LSByte of 
TDR/RDR directly, or it must write the address of the 
LSByte to the CCAR. 


The TxFIFO and RxFIFO have a maximum capacity of 
32 characters (bytes) each. The IUSC empties them 
of all data when external hardware drives the /RESET 
pin low, when software resets the serial controller via 
the RTReset bit (CCAR10), and when software writes 
a "Purge Rx and/or Tx FIFO" command to the RTCmd 
field (CCAR15-11). 


The RxFIFO becomes one byte more full for each 
character received on the serial link, and one or two 
bytes less full each time software reads data from it 
via the RDR or the Rx DMA channel writes data into 
memory. The TxFIFO becomes one or two bytes 
more full each time software writes data to it via the 
TDR or the Tx DMA channel reads data from memory, 
and one byte less full each time the Transmitter 
moves a character into its output shift register. 


The exceptions to the above statements are that in 
Async with Code Violations (1553B) mode with the 
Extended Word option selected, the RxFIFO becomes 
two bytes more full for each received word, and the 
TxFIFO becomes two bytes emptier each time the 
Transmitter transfers a word to its shift register. 


The IUSC maintains a counter for each FIFO that 
reflects its current contents. Software can read the 
number of received characters/bytes that are currently 
in the RxFIFO. To do this, it may first have to write 
the "Select RICRHi=FIFO Status" command to the 
RCmd field of the Receive Command/Status Register 
(RCSR15-12). Then software can read the MSByte of 
the Receive Interrupt Status Register (RICR15-8). 
The resulting 8-bit value represents the number of 
received characters in the RxFIFO. It ranges from 0 
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for an empty RxFIFO to 32 for a full one. Software 
can skip the step of writing the Select command if it 
hasn't written any of the other "Select RICRHi=..." 
commands to the RCSR since the last time it issued 
this command. 


Similarly, software can read the number of entries that 
are currently empty in the TxFIFO. It may first have to 
write the "Select TICRHi=FIFO Status" command to 
the TCmd field of the Transmit Command/Status 
Register (TCSR15-12). Then software should read 
the MSByte of the Transmit Interrupt Status Register 
(TICR15-8). The resulting 8-bit value represents the 
number of empty positions in the TxFIFO. It ranges 
from 0 for a full TxFIFO to 32 for an empty one. As for 
the RxFIFO, software can skip the step of writing the 
Select command if it hasn't written any of the other 
"Select TICRHi" commands to the TCSR since the last 
time it issued this command. 


The IUSC continually compares the contents of these 
counters against two "threshold" levels for each. 
Chapter 5 describes how the "Tx DMA Request Level’ 
determines how empty the TxFIFO must get before 
the Transmitter starts requesting that the Transmit 
DMA channel should read more data from memory. 
Once the Transmitter has started to request DMA 
transfer, it typically keeps doing so until the DMA 
channel has filled the TxFIFO or until the Transmit 
Character Counter has counted down to zero. 


Chapter 5 also describes how the "Receive DMA 
Request Level" controls how full the RxFIFO should 
get before the Receiver starts requesting that the. 
Receive DMA channel should move data to memory. 
Once the Receiver has started to request DMA 
transfer, it typically Keeps doing so until the DMA 
channel has emptied the RxFIFO, or until it has stored 
the last character of a frame or message. 


Chapter 6 describes how, if software enables "Trans- 
mit Data" interrupts, the "Transmit /INT Level" controls 
how empty the TxFIFO should get before the 
Transmitter starts requesting such an interrupt. It also 
describes how, if software enables "Receive Data" 
interrupts, the "Receive /INT Level" controls how full 
the RxFIFO should get before the Receiver starts 
requesting such an interrupt. Software doesn't use 
these kinds of interrupts in most IUSC applications, 
because the Transmit and Receive DMA channels 
handle the data. But if software does use data 
interrupts, the interrupt service routine should fill the 
TxFIFO or empty the RxFIFO completely each time it 
executes. (As a minimum the ISR should transfer 
enough data to bring the FIFO status below the 
threshold level, or should raise the threshold level to 
accomplish the same thing.) 


With the 16C31 and other older members of the USC 
family, certain worst-case interarrivals of serial 


clocking and bus timing could result in transient states 
in which the RxFIFO and TxFIFO counts were 
incorrect. When software read these counts and 
transferred data to the TDR or from the RDR, it could 
work around such problems by the classic control- 
system technique of reading the counts until two 
successive readings agreed. The 16C32, and similar 
devices such as the 16230 USC, include logical 
interlocks so that these counts will always be correct 
and need only be read once. 


These interlocks have also eliminated a_ related 
problem of earlier USC family members, wherein a 
received character was completed just as the Receiver 
was deciding to withdraw its Receive DMA request 
because the latter had emptied the RxFIFO. Under 
worst-case interarrivals, the logic would maintain the 
request on a 16-bit bus even though the RxFIFO 
contained only the single newly-received character. 
The DMA channel would then do a 16-bit transfer, so 
that the observable symptom of the problem was that 
occasionally, "extra characters" would appear in the 
received frame in memory. Such phenomena will not 
occur with the 16C32 and 16230. 


Between Frames, Messages, or 
Characters 


Synchronous Transmission 


When software issues a "Set EOF/EOM" command 
and then writes data to the TDR, or when software or 
the Transmit DMA channel fetches enough data so 
that the TCC counts down to zero, the IUSC flags the 
last character of the message or frame in the TxFIFO. 
After this last character gets to the other end of the 
TXFIFO and out onto the serial link, the Transmitter 
terminates the frame or message. The Transmitter 
also terminates a frame or message if it needs a 
character from the TxFIFO but it's empty (an 
“underrun" condition). The IUSC's exact actions at 
these points depend on the serial mode/protocol and 
possibly on certain programmed options. 


If the TxCRCatEnd bit in the Transmit Mode Register 
(TMR8) is 1, the Transmitter sends the CRC code it 
has accumulated during the frame, after a character 
marked as the end of a frame or message. If the 
TxSubMode field says to do so, the Transmitter sends 
its accumulated CRC in an underrun situation. The 
CRC can be 16 or 32 bits long. 


Then, or right after the last character from the TxFIFO 
if it doesn't send the CRC, except in 802.3 (Ethernet) 
mode the Transmitter sends a closing Sync or Flag 
sequence as determined by the TxMode and some- 
times the TxSubMode, as follows: 
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(TSR15-8) 
Slaved Monosync | (TSR15-8) 


ee (TSR15-8) if CMR14=0 
eee 0)(TSR15-8) if CMR14=1 
Transparent Bisync | SYN if CMR14=0 
DLE-SYN if CMR14=1 
(ASCII or EBCDIC per a 


802.3 | g02.3(Ethernet)| None sid 


HDLC/SDLC | Flag (01111110) 
HDLC/SDLC Loop | Flag (01111110) 


Then, or immediately after sending the CRC in 802.3 
(Ethernet) mode, the Transmitter decides whether to 
send another frame or message immediately or not. 
In HDLC/SDLC Loop mode only, when it sends a 
closing or idle Flag the Transmitter checks whether 
software has cleared the CMR193 bit to signal the end 
of sending activity. If so, it returns to repeating data 
from RxD onto TxD. In any other mode, and in Loop 
mode if CMR13 is 1, the Transmitter commits to 
sending a new message or frame when: 
1. there is at least one character in the TxFIFO, and 
2a. either the Wait2Send bit in the Transmit Interrupt 
Control Register (TICR2) is 0, or 
2b. software has written the "Send Frame/Message" 
command to the TCmd field of the Transmit 
Command/Status Register (TCSR15-12) since the 
end of the last frame. 






If these conditions aren't met, the Transmitter sends 
the "Idle line condition" specified by the Txidle field of 
the Transmit Command/Status Register (TCSR10-8). 
This field also determines what the Transmitter sends 
between characters in async modes. The Transmitter 
interprets Txidle as follows: 
TxId! Idle Li “ondit; 
000 The idle line condition is the 
default for the mode/ protocol 
defined by TxMode: 


* All ones in 802.3 and all 
async modes. 


* Flags in HDLC/SDLC and 
HDLC/SDLC Loop. 


* Sync sequences in Monosync, 
Slaved Monosync, Bisync, and 
Transparent Bisync. (In the 
Bisync modes these are like 
closing Syncs: they may be 
single characters or pairs 
based on CMR14.) 


Alternating zeroes and ones 
Continuous zeroes 
Continuous ones 

Reserved; do not program 
Alternating Mark and Space 
Continuous Space (TxD low) 
Continuous Mark (TxD high) 


001 
010 
O11 
100 
101 
110 
Tid 


With choices 000-011, the Transmitter encodes the 
idle condition as specified by the TxEncode field of the 
Transmit Mode Register (TMR15-13), while for 
choices 101-111 it doesn't encode the condition. 
Software can use these idle-condition options to keep 
Phase Locked Loop and decoding circuits at the 
remote receiver "in sync" between messages, frames, 
or async characters. Consider the sections of Chapter 
3 that deal with data encoding and the DPLL, and 
whatever standards or specifications apply to your 
application, in selecting how to program Txidle. 


In sync modes, once the conditions to start sending a 
message or frame (described above) are met, the 
Transmitter may send a bit sequence called a 
Preamble. A Preamble can be used to synchronize 
Phase Locked Loop and decoding circuits at the 
remote receiver, or, with the 16C32, to guarantee a 
minimum number of Flags between HDLC/SDLC 
frames. Whether the Transmitter sends a Preamble is 
a function of the TxMode and sometimes the 
TxSubMode, as follows: 


Preamble sent? 


Monosync | If CMR13=1 
Slaved Monosync | Never 

Bisync | lf CMR13=1 

If CMR13=1 
Always 

If CMR13=1 
Never 


Transparent Bisync 
802.3 (Ethernet) 
HDLC/SDLC 
HDLC/SDLC Loop 





If the Transmitter sends a Preamble, the TxPreL and 
TxPrePat fields of the Channel Control Register 
(CCR11-10 and CCR9-8) control its length and 
content: 


TxPreL Length of Preamble Sent 

00 8 bits 
01 16 bits 
10 32 bits 
11 64 bits 

TxPrePat Preamble Pattern Sent 
00 All zeroes 
01 All ones, or Flags 
10 101010... 
11 010101... 


For HDLC/SDLC mode, if TxPrePat is 01 and the 
FlagPreamble bit in the Channel Control Register 
(CCR12, see Figure 48) is 1, the 16C32 sends 1, 2, 4, 
or 8 Flags as the Preamble. Including the opening 
and closing ones, this guarantees a minimum of 3, 4, 
6, or 10 Flags between frames respectively. This is 
useful when sending to certain kinds of equipment that 
can't handle less Flags, or as a means of slowing 
down the gross frame rate slightly. 
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FlagPreambie should be 0 in all other modes. For 
802.3 (Ethernet) mode, program TxPreL=11 and 
TxPrePat=10; the Transmitter automatically modifies 
the last (64th) bit from a 0 to a 1 to act as the "start 
bit". For other modes, consider the sections of 
Chapter 3 that deal with data encoding and the DPLL, 
and whatever standards or specifications apply to your 
application, in deciding whether to use a preamble and 
if so what kind. 


After sending the Preamble, or when the conditions for 
starting a frame have been met if there is no 
Preamble, except in 802.3 (Ethernet) mode the 
Transmitter sends an opening Flag or Syne sequence. 
In the two Bisync modes this may differ from the 
closing sequence: 


Monosync | (TSR15-8) 


Slaved Monosync | (TSR15-8) 
coe canis a) 


Transparent Bisync | DLE-SYN 
(ASCII or EBCDIC per CMR12) 


HDLC/SDLC | Flag (01111110) 
DLC/SDLC Loop | Flag (01111110) 


In the HDLC/SDLC and HDLC/SDLC Loop modes 
only, the Transmitter will combine the closing and 
opening Flags into a single instance if all of the 
following are true: 

1. software has not selected sending a Preamble 
(CMR13=0; this doesn't apply in Loop mode), 

the Wait2Send bit (TICR2) is 0, and 

at least one character is available in the TxFIFO 
as the Flag is going out. 
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As described in the earlier section Status Reporting, 
software can use four of the bits in the Transmit 
Command/Status Register (TCSR) to track the 
progress of the Transmitter through these inter-frame 
activities. They occur in the time order CRCSent, then 
EOF/EOM Sent, IdleSent, and finally PreSent. 
Chapter 6 describes how software can enable any or 
all of these conditions to cause an interrupt. 


Async Transmission 


As described in the previous section, the Txldle field of 
the Transmit Command/Status Register (TCSR10-8) 
controls what kind of idle line condition the Transmitter 
sends between characters (or words) in asynchronous 
modes. The bits in the Channel Command Register 
that define the Preamble in sync modes (CCR11-8) 
can be used in Async mode to "shave" the length of 
transmitted Stop bits. 


Synchronous Reception 


Between the end of one message or frame and the 
start of the next, the Receiver goes through states that 
are similar to the inter-message or inter-frame 
activities that are described above for the Transmitter. 
As covered in the earlier section Status Reporting, 
software can use some or all of the following status 
bits to track these state changes: RxBound (RCSR4), 
CRCE/FE (RCSR8), IdleRcved (RCSR6), and 
ExitedHunt (RCSR7). If the DPLL is used, chapter 3 
describes the DPLLSync bit in the Channel 
Command/Status Register (CCSR12) which bears a 
certain symmetry with the PreSent bit on the Transmit 
side. Chapter 6 describes how software can enable 
the RxBound, IdleRcved, and/or Exited Hunt condi- 
tions to cause an interrupt. 


The IdleRcved logic isn't as flexible as the corres- 
ponding Txldle logic in the Transmitter, in that it only 
detects an Idle condition consisting of (15 or 16) 
consecutive ones. 


In HDLC/SDLC mode the Receiver automatically 
copes with single Flags between frames and with 
shared zeroes between Flags (011111101111110). 


Synchronizing Frames/Messages with 
Software Response 


In some applications, software can simply set up DMA 
buffers for multiple frames or messages, and set the 
[USC's Transmitter and/or Receiver and DMA chan- 
nel(s) into operation to send and/or receive all of them. 
In other applications, software has to interact with and 
supervise the communications process more closely. 
(The extreme case is when software has to check 
status register bits for each character that it transfers 
to the TxFIFO or from the RxFIFO.) 


The IUSC provides two alternatives for interlocking the 
start of transmission of a frame or message with 
software response, and one similar interlock on the 
receive side. 


If the Walt2Send bit in the Transmit Interrupt Control 
Register (TICR2) is 1, then each time the Transmitter 
finishes sending a frame and before it sends the next, 
it waits for software to write the Send Frame/ Message 
command to the TCmd field of the Transmit 
Command/Status Register (TCSR15-12). Depending 
on the programmed mode the Transmitter may then 
go on to send the Preamble or the opening Sync or 
Flag. This kind of interlock allows the software to re- 
program global Transmitter parameters that may need 
to change between frames or messages. It allows the 
Transmit DMA channel (or software) to fill the TxFIFO 
in preparation for the next frame or message, before 
software issues the Send Frame/Message command. 
One use for this interlock would be to change the 
TxCRCatEnd bit in the Transmit Mode Register 
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(TMR8) between frames, in an application in which the 
Transmitter should calculate a CRC code in some 
messages or frames but not in others. 


If the Wait4TxTrig bit in the Channel Control Register 
(CCR13) is 1, then each time the Transmitter finishes 
sending a frame and before it sends the next, it waits 
for software to issue the Trigger Tx DMA (or Trigger 
Rx and Tx DMA) command before it requests DMA 
operation. This is a "more stringent" interlock than the 
preceding one, in that the Transmit DMA channel 
won't fill the TxFIFO in preparation for the next frame, 
until software issues the command. This kind of inter- 
lock is useful if DMA-related parameters, or param- 
eters that go through the TxFIFO with the data, need 
to be changed between frames. The most obvious 
example is reprogramming the buffer location and 
length in the Transmit DMA channel, although the 
DMA section provides three different modes that do 
this more efficiently. 


On the Receive side, if the Walt4RxTrig bit in the 
Channel Control Register (CCR5) is 1, then after the 
Receive DMA channel has written a character marked 
as RxBound to memory (and after it has written the 
Receive Status Block if software has enabled this 
feature), the Receiver doesn't assert /RxXREQ to the 
Receive DMA channel again until software writes the 
Trigger Rx DMA (or Trigger Rx and Tx DMA) 
command to the RTCmd field of the Channel 
Command/Status Register (CCAR15-11). Software 
can use this interlock to reprogram the Receive DMA 
channel between frames. 


5. Direct Memory Access (DMA) Channels 


The main advantage of the IUSC, compared to prede- 
cessor devices like the 16C3x MUSC, is the inclusion 
of Transmit and Receive DMA channels. These allow 
the IUSC to fetch its own transmit data from memory 
and store its received data in memory. This chapter 
describes the various operating modes of these DMA 
channels and how to program the |USC for them. 


The IUSC's Receiver and Transmitter can be handled 
via DMA or programmed transfers. Software can 
even mix DMA and programmed transfers for the 
Receiver or the Transmitter. 


For example, software could use the Wait4RxTrig bit 
(CCR13) to inhibit DMA transfers at the start of each 
received frame, so that it can read the first few char- 
acters of the frame from the RxFIFO itself. Software 
can then determine the kind of frame from examining 
the first characters, optionally program the Rx DMA 
controller accordingly, and then write the "Trigger Rx 
DMA" command to the RTCmd field of the Channel 
Command/Address Register (CCAR15-11). The DMA 
controller can then transfer the rest of the frame into 
memory without further software intervention. 


DMA Fundamentals 


Each channel can operate in any of four main 
operating modes. Figure 52 shows the format of the 
Transmit and Receive DMA Mode Registers (TDMR 
and RDMR). The DMAMode fields of these registers 
control the main mode of each channel, and are 
encoded as follows: 


DMAMode Basic DMA Mode 
00 Single Buffer 
01 Pipelined 
10 Array 
11 Linked List 


Later sections will describe each of these modes in 
detail, but first it's worthwhile to present some charac- 
teristics that are common to all the modes. 


Addresses and Byte Counts 


Before the Transmit DMA channel can transfer data 
from a memory buffer to the TxFIFO, and before the 
Receive DMA channel can transfer data from the 
RxFIFO to a memory buffer, software and/or hard- 
ware (depending on the mode) has to load the data 





DMAMode /RSB AddrMode TermE| 8/16 | CONT} GLink | BUSY | INITG 
Count EOL 
| InA/L 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


buffers starting address into the Transmit or 
Receive Address Register (TAR or RAR). The 
same software/hardware mechanism has to load the 
number of bytes to be read out of the buffer into the 
Transmit Byte Count Register (TBCR), or load the 
(maximum) number of bytes to be written into the 
buffer into the Receive Byte Count Register 
(RBCR). The TAR and RAR are 32-bit registers, 
allowing the IUSC to address up to a 4-gigabyte linear 
address space, while the TBCR and RBCR are 16-bit 
registers, allowing a channel to transfer up to 65,535 
bytes to or from each buffer. (In Single-Buffer and 
Pipelined modes, a zero byte count makes a channel 
do nothing, while in Array and Linked List modes, a 
zero byte count indicates that the last requested 
buffer has been completed.) In any mode, a block of 
data longer than 65,535 bytes can be easily 
transferred, simply by treating it as two or more 
consecutively-addressed buffers. 


The 32-bit TAR and RAR are each divided into two 
16-bit registers, with the less significant half being 
called Lower (TARL, RARL) and the more significant 
half being called Upper (TARU, RARU), In Single- 
Buffer and Pipelined modes, software must program 
address registers directly; they are arranged with the 
Lower register at the lower register address, which 
sounds right but is in fact the natural order only for 
little-Endian systems (Z80 family or 8086 family 
processors). On Big Endian machines, including 
Z8000 and 680x0 processors, software should not 
program an address register using an instruction that 
moves 32-bit data, but rather by means of two 
separate instructions each transferring 16 bits. 


Aside from certain "overhead" memory operations in 
Array and Linked List modes, each DMA channel 
actually transfers data only when the serial Receiver 
or Transmitter requests that it do so, using an internal 
request signal. Programming the DMA Request 
Levels, later in this chapter, describes how software 
can program the number of received characters in the 
RxFIFO at which the Receiver requests DMA transfer, 
and the number of empty slots in the TxFIFO at which 
the Transmitter does so. 





Figure 52. The DMA Mode Registers (TDMR and RDMR) 


Data Width and Byte Ordering 


lf "16Bit" in the Bus Configuration Register (BCR2) is 
0, indicating an 8-bit external data bus, and/or if the 
8/16 bit in a channel's DMA Mode Register (TDMR8 
or RDMR8) is 1, the channel does only 8-bit transfers 
with memory, including data buffer transfers and 
"array" and "list" accesses in Array and Linked List 
modes. The channel decrements its Byte Count 
Register (TBCR or RBCR) by 1 for each transfer to or 
from a data buffer. Typically it also increments its 
address register by 1 for each byte transfer, although 
software can program a channel to keep a data buffer 
address constant, or decrement it. If 16Bit is 0, the 
IUSC transfers all bytes on the AD7-0 lines. If 16Bit 
and 8/16 are both 1, and address incrementing or 
decrementing is enabled, the Transmit DMA channel 
provides each byte on both halves of the data bus, 
_ while the Receive DMA channel alternates between 
taking a byte from AD15-8 and from AD7-0, as deter- 
mined by bit O of its address register. Chapter 4 
describes the "Select D15-8 First" or "Select D7-0 
First" commands that software can write to the CCAR; 
these affect how the channel relates address bit 0 to 
AD15-8 and AD7-0. 


lf 16Bit is 1 and 8/16 is 0, a 16C32 DMA channel will 
do 16-bit transfers whenever it can. This includes all 
array and list transfers in Array and Linked List 
modes, and all transfers to and from data buffers 
when the address in TAR or RAR is even and TBCR 
or RBCR contains 0002 or more. The 16C32 is more 
flexible than the 16C31 in that, if the address in TAR 
or RAR is odd, and/or if the byte count in TBCR or 
RBCR is 0001, it will do a byte transfer with memory. 
(This can happen only for the first byte and last bytes 
of a buffer.) In such transfers the Receive channel 
will take the byte from AD15-8 or AD7-0 according to 
bit O of its address register, interpreted according to 
any "Select D15-8 First" or "Select D7-0 First" 
command that software has written to the CCAR. 


When an IUSC does a 16-bit transfer to or from a 
memory buffer it decrements TBCR or RBCR by 2, 
and typically increments its address register by 2. For 
serial data, the IUSC arranges the oldest and second- 
oldest characters from the RxFIFO on the AD15-0 
lines, or routes the two characters on these lines into 
the TxFIFO, according to any "Select D15-8 First" or 
"Select D7-0 First" command that software has written 
to the CCAR. 


There is one other feature of the 16C32's byte/word 
switching mechanism that software needs to know 
about. When a channel is programmed for 16-bit 
transfers and for Early Termination as described in 
the next section, and the last character of a frame 
falls at an even memory address, the serial controller 
signals the DMA channel that the current transfer 


includes the last character of a frame, but it doesn't 
indicate whether this character is the first or second of 
the two characters in the transfer. That is, it doesn't 
tell the DMA channel whether or not to force a byte 
transfer. On the receive side this is not a big problem, 
because if such an end-of-frame character is the 
oldest one in the RxFIFO, the IUSC provides it on the 
“even-addressed" half of the data bus. On the trans- 
mit side this isn't a problem in a Little-Endian system, 
because when the TCC contains 0001 the serial con- 
troller always takes the last byte from AD7-0, which is 
the even-addressed location in such systems. On the 
Transmit side in a Big-Endian system, software can 
avoid this situation by not programming the Transmit 
DMA channel for Early Termination, but rather setting 
the byte count for the last buffer of the frame to match 
the frame length used by the TCC. 


Buffer Termination 


A DMA channel transfers data from memory to the 
TxFIFO as the Transmitter requests it, or from the 
RxFIFO to memory as the Receiver requests such 
transfer, until one of the following occurs: 


1. The channel decrements the count in TBCR or 


80 


RBCR to zero. 

If the TermE bit in the DMA Mode Register 
(TDMR9 or RDMR39) is 1, and the serial controller 
signals for a "buffer termination". 


External hardware asserts the /ABORT input 
during a DMA transfer. 
Host software writes one of the following 
commands to the DMA Command / Status 
Register (DCAR): 

"Reset This Channel", 

"Pause This Channel", 

"Abort This Channel", 

"Reset All Channels", 

“Pause All Channels", or 

"Abort All Channels". 


When a channel stops because of 3 or 4 above, it 
does so summarily, without any further actions. But 
when a channel terminates a buffer for reason 1 or 2, . 
it attempts to go on to another buffer, except in Single 
Buffer Mode. In Pipelined mode, if software has pro- 
vided the address and byte count of the next buffer, 
the channel continues on to transfer that buffer; 
otherwise it stops. In Array or Linked List, the channel 
tries to fetch the address and byte count of the next 
buffer from the array or list in memory; if it finds them 
it continues on to transfer that buffer, otherwise it 
stops. 


Point 2 above notes that if the TermE bit in a DMA 
Mode Register (TDMR9 or RDMR39) is 1, the channel 
will terminate a memory buffer before it decrements 
its byte count (in TBCR or RBCR) to zero, if/when the 


2. 


serial controller asserts a termination signal. 
TermE is 0, the channel ignores the signal.) 


(If 


The serial controller asserts the internal termination 
signal to the Transmit DMA channel only in synch- 
ronous modes. It does so as the DMA channel writes 
1 or 2 characters into the TxFIFO, so that the Trans- 
mit Character Counter (TCC) is decremented to 0. 


On the receive side, the Receiver forces the Request 
signal True to the Receive DMA channel, as/after it 
places an RxBound character in the RxFIFO in 
HDLC/SDLC, Ethernet/802.3, Transparent Bisyne, or 
1553B mode. It does this to force the DMA channel 
to store the end of the frame or message, and does it 
without regard for the number of received characters 
in the FIFO. The serial controller then maintains the 
request until the DMA channel stores the RxBound 
character (and the Receive Status Block if it's 
enabled) in memory. The serial controller asserts 
buffer termination as the DMA channel stores these 
last bytes. (Early termination signalling on the receive 
side is actually more complex than we need to know 
about at this point. The full story is told later in 
Storing Receive Status Blocks.) 


The Receive Character Counter (RCC) feature can 
neither cause early buffer termination nor forcing of 
the internal DMA Request. 


Single Buffer Mode 


This is the most basic of the IUSC DMA channels’ 
major modes. 


Figure 53 illustrates Single Buffer mode. Software 
loads the starting address of each memory buffer 
containing data to be transmitted into the Transmit 
Address Register (TAR). Similarly, it loads the 
starting address of each memory area, into which 
received data should be stored, into the Receive 
Address register (RAR). The software also loads the 
number of characters to be transmitted from each 
memory area into the Transmit Byte Count Register 
(TBCR). Similarly, it loads the maximum number of 
received characters to be stored in each memory area 
into the Receive Byte Count Register (RBCR). 


Then the host processor software enables the DMA 
channel for operation by writing a "Start This Channel" 
command to the DMA Command / Address Register 
(DCAR). Thereafter the DMA channel moves the data 
from memory to the TxFIFO or from the RxFIFO into 
memory, as described in DMA Fundamentals above. 


Software can program the IUSC to request several 
kinds of interrupts at the end of the buffer. A DMA 
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channel interrupt, an interrupt request from the serial 
controller, or both can be used to trigger host software 
response at appropriate points in the serial data 
stream. Alternatively, host software can periodically 
poll the DMA channel status in the DMA Mode 
Register (TDMR or RDMR) and/or the serial channel 
status to determine when the DMA transfer is over. 


Note that for transmitting, the DMA channel completes 
its operation before the serial Transmitter has finished 
sending all the data in the block. For reception the 
serial Receiver may know about an end-of-block 
situation before the Receive DMA channel has 
finished transferring the data into memory. 


When an interrupt or polled status has informed the 
host software that a DMA block transfer is over, the 
software can read back the ending contents of the 
TAR or TBCR to figure out whether all of the bytes to 
be sent actually were sent. Similarly, software can 
read back the ending contents of the RAR or RBCR to 
determine how many bytes the channel stored in 
memory. Note that software can read similar infor- 
mation from the RCC FIFO in the serial controller, or 
can have the IUSC store it in memory in a Receive 
Status Block. 


Particularly for receiving, host software will typically 
want to reprogram the RAR and RBCR, or TAR and 
TBCR, and restart the channel for the next block of 
data, as soon as possible after the DMA channel 
finishes with each block. 


In many applications, data from two or more memory 
areas must be sent without interruption on the serial 
link (é.g., in the same frame). The corresponding 
characteristic on the receive side is almost always 
required, namely that received data not be lost while 
the host software responds to a_ buffer-complete 
condition, reprograms the channel for the next buffer, 
and restarts the channel. 


While the IUSC's deep FIFOs provide some assur- 
ance of continuous transmission and _ protection 
against loss of receive data, above a certain bit rate 
these characteristics can only be assured by using 
Pipelined, Array, or Linked List mode. The actual rate 
at which Single-Buffer mode is no longer sufficient is a 
fairly complex matter involving processor speed and 
system architecture. 


(1) Host Software Sets Up the Channel 
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(2) The Channel Transfers Data 
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Figure 53. Single Buffer Mode DMA Operation 
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Pipelined Mode 


In this mode the IUSC employs two additional regis- 
ters for each channel, called the Next Transmit 
Address Register (NTAR), the Next Transmit Byte 
Count Register (NTBCR), the Next Receive Address 
Register (NRAR), and the Next Receive Byte Count 
Register (NRBCR). Figure 54 illustrates Pipelined 
mode, in which software can write the starting 
address and byte count for the next data buffer into 
these registers, while the DMA channel is using the 
TAR and TBCR, or RAR and RBCR, to transfer the 
preceding buffer. 


After programming a Channel Mode Register for Pipe- 
lined mode, the host software can start the channel in 
one of two ways. It can program the address and 
length of the first buffer into the TAR and TBCR, or 
RAR and RBCR, and then write the "Start This Chan- 
nel" command to the DCAR. Alternatively, software 
can also write the address and length of the second 
buffer into the NTAR and NTBCR, or NRAR and 
NRBCR, and then write the "Start/Continue This 
Channel" command to the DCAR. The latter com- 
mand differs from the former in that, in addition to 
setting the BUSY bit in the channel's DMA Mode 
Register (TDMR5 or RDMRS8), it also sets the CONT 
bit (TDMR7 or RDMR7). 


Whichever way software starts the channel, it then 
transfers from the data buffer indicated by TAR and 
TBCR, or into the buffer indicated by RAR and RBCR, 
as described earlier in DMA Fundamentals. 


lf a new transmit buffer is available in Pipelined mode 
and the CONT bit is zero, while the Transmit DMA 
channel is still transferring an earlier buffer, software 
should write the address and byte count of the new 
buffer into the NTAR and the NTBCR, and then write 
a "Start/Continue This Channel" command for the 
Transmit DMA channel into the DCAR. If it accom- 
plishes these things before the DMA channel finishes 
transferring the preceding buffer from memory to the 
TxFIFO, then when the channel finishes with the 
preceding buffer, it automatically transfers the 
contents of the NTAR and NTBCR to the TAR and 
TBCR respectively, and continues sending the data in 
the new buffer. 


Similarly, if an empty receive buffer is available and 
the CONT bit is zero, while the Receive DMA channel 
is still transferring an earlier buffer, software should 
write the address and byte count for the buffer into the 
NRAR and the NRBCR, and then write the "Start/ 
Continue This Channel" command for the Receive 
DMA channel into the DCAR. If it accomplishes these 
steps before the channel finishes transferring the 
preceding buffer from the RxFIFO to memory, then 
when the DMA channel finishes with the preceding 
buffer, it automatically transfers the contents of the 
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NRAR and NRBCR to the RAR and RBCR respec- 
tively, and goes on to receive data into the new buffer. 


In Pipelined mode, a DMA channel tries to advance to 
the next buffer when it has decremented the TBCR or 
RBCR to 0, and/or if software enables the early buffer 
termination feature and the serial controller signals for 
termination. In either case the channel does so only if 
the CONT bit in its DMA Mode Register (TDMR7 or 
RDMR7) is 1. The channel sets the CONT bit when 
software writes a "Start/Continue" command to the 
DCAR, and clears the bit each time it advances to a 
new buffer. 


A DMA channel will not advance to the next buffer in 
response to assertion of the /ABORT signal during a 
transfer. Nor will it advance to the next buffer in 
response to any software commands. 


As in Single Buffer mode, software can program the 
IUSC to request a DMA channel interrupt and/or a 
serial controller interrupt as these modules finish with 
each buffer. Alternatively, host software can period- 
ically poll the DMA channel status and/or the serial 
channel status to track the progress of DMA transfer. 


Avoiding Problems with the CONT Flag 


Software must take care not to write a "Start/ 
Continue" command to an operating channel while the 
channel is testing the CONT bit after completing a 
buffer. This is because, if the command occurs just 
after the channel has tested CONT as Q and therefore 
cleared BUSY, the command restarts the channel to 
reuse the buffer described by TAR and TBCR, or RAR 
and RBCR, a second time. 


The performance and interrupt-response character- 


istics of the processor and total system, considered in 


the context of the line protocol, may guarantee that 
software will always write the Start/Continue com- 
mand for a buffer before the channel finishes with the 
previous one. But if this is not so, software should 
approach "notifying" the channel of a new buffer as 
shown in Figure 55. First, clear the Master Bus 
Request Enable bit (MBRE; DCAR8) and then test the 
BUSY bit (xDMRS5). If BUSY is 1, write the register 
address and length to NxAR and NxBCR and then 
issue the "Start/Continue This Channel" command. If 
i's 0, write the address and length to xAR and xBCR 
and then issue the "Start This Channel" command. 
Be sure to set MBRE when writing either command, 
so that the channel(s) can operate again. 


One drawback of Pipelined mode (as well as Array 
and Linked List modes), compared to Single-Buffer 
mode, is that host software can't read back the ending 
address and byte count to figure out the exact 
completion status of the buffer. For receiving, similar 
information can be obtained by using the Receive 
Status Block feature of the serial controller. 


(1) Host Software Sets Up the First Buffer 
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(2) Host Sets Up the Next Buffer while the Channel Transfers Data 
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Data Buffer "1" In Memory 


DCAR a 
1 
CONT 
Data Buffer "2" in Memor 
(TOCMR7 or RDCMR7) y 
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Figure 54. Pipelined Mode DMA Operation 
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with MBRE=1 


Figure 55. Posting a New Buffer (Pipelined Mode) 


Write Start/Continue 
command to DCAR, 
with MBRE=1 





Done 


Array Mode 


In Array mode, host processor software sets up an 
arbitrarily long array or table of buffer addresses and 
byte counts in memory. Then it sets the DMA channel 
into operation to send all the data in all the buffers, or 
to receive data into all of them in turn. 


The Array and Linked List modes differ from Pipelined 
mode in that software does not write the address of a 
data buffer into the Next Transmit Address Register 
(NTAR) or Next Receive Address Register (NRAR). 
Instead, in Array mode, it writes NTAR or NRAR with 
the address of the start of an array in memory, that 
contains the addresses and lengths of each of a 
whole set of data buffers. 


Figure 56 illustrates Array mode operation. Each 
entry in the array may be six or 12 bytes long, as 
described in the later sections Fetching Transmit 
Status Blocks and Storing Receive Status Blocks; the 
Figure shows 6-byte entries to keep it as simple as 
possible. With either entry format, the first 4 bytes of 
each entry are the 32-bit buffer address and the next 
two bytes are the 16-bit byte count for the buffer. 


Software can program the order in which the channel 
fetches the two halves of the address to match the 
characteristics of the host processor, as described 
later in Format of Binary Values in Arrays and Lists. |f 
16Bit (BCR2) is O and/or the 8/16 bit (TDMR8 or 
RDMR8) is 1, this parameter defines the order in 
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which the channel fetches the 4 bytes of the address 
and the 2 bytes of the count. 


After programming a Channel Mode Register for Array 
mode, software should start the channel by program- 
ming NTAR or NRAR to point to the array at the 
address of the first buffer to be used, and writing a 
"Start/Init This Channel" command to the DCAR. This 
command differs from a "Start This Channel" com- 
mand in that it set the INITG bit in the channel's DMA 
Mode Register (TDMR4 or RDMR4) as well as the 
BUSY bit (TDMR5 or RDMRS8S), so that the channel 
fetches the first array entry before starting DMA data 
transfer. 


After the channel fetches a buffer's address and byte 
count, and verifies that the byte count is non-zero, if 
the ClearCount bit in the channel's DMA mode 
register (TDMR12 or RDMR12) is 1, the channel 
clears the byte count field of the entry, by writing zero 
to it. (Software can use this feature to track the DMA 
channel's progress through the array, but the main 
purpose of the feature is in Linked List mode.) 


On the Transmit side, if the channel's TCBinA/L bit 
(TDMR13) is 1, the channel next reads but discards 
the last 6 bytes of the entry. (If a subsequent entry in 
the array aligns with the start of a frame, the DMA 
channel will fetch a Transmit Control Block from the 
first 2 or 4 of these bytes.) 


At this point, if and when the internal Request signal 
from the Transmitter or Receiver is true, the DMA 
channel begins transferring data to or from the first 
buffer in memory, as described earlier in DMA Funda- 
mentals. (On the Transmit side, if Transmit Control 
Blocks are enabled the Transmitter may interpret the 
first 2 or 4 bytes from the buffer as a TCB.) 


As in other modes, a DMA channel typically finishes a 
buffer when it has decremented a buffer's byte count 
to zero, and/or if the TermE bit in the channel's DMA 
Mode Register (TDMR9 or RDMR39) is 1 to enable the 
Early Buffer Termination feature and the serial 
controller signals that the current transfer includes the 
last character of a frame or message. 


On the Receive side, if Receive Status Blocks are 
enabled as described in Chapter 4, after the Receive 
DMA channel stores a character marked with 
RxBound status, the Receiver maintains its request to 
the DMA channel until the latter has read out the 2- or 
4-byte RSB. (The Receiver does this whether or not 
Early Termination is enabled,) If the RSBinA/L bit in 
the Receive DMA Mode Register (RDMR13) is 0, the 
channel writes the RSB into the data buffer after the 
last character of the frame. If RSBinA/L is 1, the 
channel writes the RSB into the array entry after the 
byte count, and then writes zero to the next 2-4 bytes. 


(1) Host Software Sets Up the Array and Starts the Channel, 
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The DMA channel then tries to advance to the next 
buffer in the array, reading the next address and byte 
count as it did for the first buffer. When the channel 
fetches a zero byte count from an array entry, it goes 
to an inactive state, in which case the software must 
reprogram the channel and restart it before it can 
perform further DMA transfers. 


In Array mode a channel uses NTBCR or NRBCR 
only as a temporary holding register, so software 
doesn't have to set up this register. In particular, 
NxBCR does NOT specify the length of the array -- 
rather, a zero in the byte count field of an entry 
signals the end of the array. 


Software can program the IUSC to interrupt when the 
DMA channel and/or the serial controller completes 
each data buffer, and/or when the DMA channel 
reaches the end of the array. Host software can track 
the channel's progress through the array by reading 
back the address in the NTAR or NRAR. 


In Array mode a DMA channel becomes more auto- 
nomous and independent of processor response than 
in Pipelined mode. In general, this mode is less 
dependent on processor action than is Pipelined 
mode. This is particularly important when several 
short frames arrive and must be placed into consec- 
utive buffers. 


But in one way Array mode is more dependent on 
host processor response than is Pipelined mode. 
When the DMA channel comes to the zero buffer 
length that signals the end of the array, it becomes 
inactive and waits for host processor software action, 
just as in Single Buffer mode. Presumably on the 
transmit side, each array can be made to end at the 
end of a message or frame, so that this characteristic 
should not cause any problems. But, on the receive 
side, the serial controller may be subject to FIFO 
overruns and lost data if the host processor software 
doesn't reprogram the DMA channel with a new array 
in a timely manner. 


Linked List Mode 


This mode is similar to Array mode, particularly in its 
capability to switch buffers rapidly for each of multiple 
successive short frames, but it adds a capability for 
dynamic updating as in Pipelined mode. 


In Linked List mode the DMA channel fetches a buffer 
address and a byte count from the first six bytes of a 
list entry for each buffer, just as in Array mode, but in 
Linked List mode these entries don't have to follow 
one another in memory. The difference between 
array entries and list entries is that each list entry 
includes the 32-bit address of the next entry. As in 
array mode, a zero in the byte count field of an entry 
signals the end of the list, and the other fields in such 
a final entry don't matter. 
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List entries can be 10 bytes long or 16 bytes long, 
depending on whether they include a Transmit Control 
Block or Receive Status Block, as described in the 
later sections Fetching TCBs and Storing RSBs. 
(Figure 57 shows 10-byte entries to keep it as simple 
as possible.) With either entry format, the first 4 bytes 
of each entry are the 32-bit buffer address and the 
next two bytes are the 16-bit byte count for the buffer. 


As in Array mode, software can control the order in 
which the channel fetches the two halves of each 
address. When a channel is restricted to byte trans- 
fers, this option controls the order in which it fetches 
the 4 bytes of the address and the 2 bytes of the byte 
count. 


After programming a Channel Mode Register for 
Linked List mode, host software typically starts the 
channel by programming NTAR or NRAR to point to 
the linked list at the address of the first buffer to be 
used, and then writing a "Start/Init This Channel" 
command to the DCAR. This command differs from 
"Start This Channel" in that it set the INITG bit in the 
channel's DMA Mode Register (TDMR4 or RDMR4) 
as well as the BUSY bit (TDMR5 or RDMRS8), which 
makes the DMA channel fetch the first list entry 
before beginning DMA data transfer. 


After the channel fetches a buffer's address and byte 
count, and verifies that the byte count is non-zero, if 
the ClearCount bit in the channel's DMA Mode 
Register (TDMR12 or RDMR12) is 1, the channel 
clears the byte count field of the entry, by writing zero 
to it. This feature is especially valuable when soft- 
ware arranges the linked list in a "ring" structure, as 
described later. 


On the Transmit side, if the channel's TCBinA/L bit 
(TDMR13) is 1, the channel then reads but discards 
the next 6 bytes of the entry. (If a subsequent entry 
aligns with the start of a frame, the DMA channel will 
fetch a Transmit Control Block from the first 2 or 4 of 
these bytes.) 


At this point, when the internal Request signal from 
the Transmitter or Receiver is true, the DMA channel 
transfers data to or from the first buffer in memory, as 
described earlier in DMA Fundamentals. (On the 
Transmit side, if Transmit Control Blocks are enabled, 
the Transmitter may interpret the first 2 or 4 bytes 
from the buffer as a TCB.) 


As in other modes, a DMA channel typically finishes a 
buffer when it has decremented a buffer's byte count 
to zero, and/or if the TermE bit in the channel's DMA 
Mode Register (TDMR9 or RDMR39) is 1 to enable the 
Early Buffer Termination feature, and the serial con- 
troller signals that the current transfer includes the last 
character of a frame or message. 


(1) Host Software Sets Up the Linked List and Starts the Channel, 
which Fetches the First Entry and then Clears the Byte Count 
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Figure 57. Linked List DMA Mode with a Three-Buffer Ring (1 of 2) 
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(3) The Channel Moves to Buffer 2, 
and Requests a Host Interrupt 


Address in 
Linked List 


NTAR or NRAR 


Buffer 1 
Address 


0000 


Address of 
Buffer 2 Entry 


Buffer 2 
Address 


Buffer 3 
Address 


Buffer 3 Length 
Address of 
Buffer 1 Entry 


Data to Transmit, or Empty for Receive 


Data Buffer "3" In Memory 


DD 


Buffer 2 Length 


H — Addrebs of 
Buffer 3\Entry 


Transmitted or Received Data 


Data Buffer "1" In Memory 


Buffer 2 
Address 


TAR or RAR 


Buffer 2 Length 


Host 


—_> 
TBCR or RBCR 


Addr 


Data to Transmit, or Empty for Receive 


Data Buffer "2" In Memory 





Figure 57. Linked List DMA Mode with a Fixed Three-Buffer Ring (2 of 2) 


On the Receive side, if Receive Status Blocks are 
enabled as described in Chapter 4, after the Receive 
DMA channel stores a character marked with 
RxBound status, the Receiver maintains its DMA 
request until the channel has read out the 16- or 32- 
bit RSB. (It does this whether or not Early Termi- 
nation is enabled.) If the RSBinA/L bit in the Receive 
DMA Mode Register (RDMR13) is 0, the channel 
writes the RSB into the data buffer after the last 
character of the frame. If RSBinA/L is 1, the channel 
writes the RSB into the list entry after the byte count, 
and then writes zeroes to the next 2 or 4 bytes. 


The DMA channel then tries to advance to the next 
buffer in the list, by first fetching the address of the 
next entry (this address follows the byte count if the 
TCBinA/L or RSBInA/L bit is 0, otherwise it follows the 
last unused byte). Then the DMA channel fetches the 
buffer address and byte count from the next entry. 


If the next byte count is non-zero, the channel con- 
tinues to transfer data to or from the new buffer. If the 
byte count is zero, the channel goes to an inactive 
state, in which case software must reprogram and re- 
start the channel before it can transfer any more data. 


Software can program the IUSC to interrupt the pro- 
cessor when the DMA channel and/or serial controller 
completes each data buffer, and/or when the DMA 
channel reaches the end of the linked list. Host soft- 
ware can track the channel's progress through the list 
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by reading back the address in the NTAR or NRAR. 


Using Linked List Mode to Create a Buffer Ring 


Figure 57 illustrates operation in Linked List mode. In 
the application shown, DMA transfers and software 
processing of the data rotate among a fixed set of 
three buffer areas in memory. The _ next-entry 
addresses in their list entries configure the list as a 
"circular ring". This is the kind of application for which 
the ClearCount bits are provided on the 16C32. 


In the first part of the Figure, software starts the DMA 
channel, to transfer data into or out of buffer "1". The 
host processor (or another hardware element) is 
putting new transmit data into buffer "3", or is taking 
received data out of "3". While it's doing so, the byte 
count field for buffer 3 remains zero. 


As described earlier, when a channel's ClearCount bit 
(TOMR12 or RDMR12) is 1, the channel writes zero 
into the byte count field of each buffer's list entry, after 
it has read the count and found it to be non-zero. 
This zero byte count prevents the DMA channel from 
circling around the ring and reusing the buffer again, 
before the software has filled or emptied the buffer 
and then "refreshed" the byte count. 


In the second part of the Figure, software (or what- 
ever) finishes filling or emptying buffer "3", and 
software places a non-zero byte count in its list entry. 


It needs to do this with care to avoid problems if the 
DMA channel accesses the end of the list at (more or 
less) the same time. The following procedure is 
recommended: 


ja. On a 16-bit bus, store the byte count using a 16- 
bit write operation, OR 

1b. on an 8-bit bus, write the Master Bus Request 
Enable Bit (MBRE, DCAR8) to 0, then write the 
two halves of the byte count, then write MBRE 
back to 1. 


2. Read the TDMR or RDMR and test the DMA 
channel's BUSY bit. If it's 0, the channel fetched 
the byte count as zero before we stored the new 
value, and must be restarted -- go to a routine 
that does this. If BUSY is still 1, the newly filled or 
emptied buffer has been successfully added to 
the list and will be handled by the DMA channel. 


In the third part of the Figure, the channel finishes 
sending data from buffer "1" or receiving data into it. 
It request an interrupt on the host processor, and 
goes on to buffer "2", clearing its byte count. The 
interrupt triggers the software to empty or fill buffer "1" 
and then set its new byte count. 


Adding a Buffer to the End of a List 


On other systems, buffers are not arranged in a ring, 
but are passed from one software routine to another 
as they're filled and emptied. In such systems, soft- 
ware may set the ClearCount bit for progress-tracking 
reasons, but doesn't need to do so. In this case, the 
procedure that software be careful with is that of 
adding a buffer to the end of a linked list for an 
operating DMA channel. It should do so as follows: 


1. Create a list entry for the new buffer -- often one 
exists and simply needs its buffer address and/or 
byte count "refreshed". Place the address and © 
count in the entry, along with the TCB for a 
transmit buffer if this feature is used. 


2. Place the address of an "end of list" entry (one 
that includes a zero byte count) in the next entry 
address field of the new list entry. 


3. Locate the list entry for the previous last buffer in 
the list. (This entry will also have its "next entry 
address" pointing to an "end-of-list" entry.) 

4a. If the processor and system bus are both 32 bits 
wide, or if it can be otherwise ensured that the 
software can write a 32-bit address into memory 
without interference from 16C32 activity, software 
can simply write the address of the new entry into 
the next entry address field of the entry for the 
previously last buffer. 

4b. Otherwise, software should write the Master Bus 
Request Enable bit (MBRE; DCAR8) to 0, then 
write the address of the new entry into the next 
entry address field of the entry for the previously 


last buffer, and then set MBRE back to 1 again. 


5. In systems that use the MaxxXfers or MaxCLKs 
fields of the Burst/Dwell Control Register (BDCR) 
to "throttle" the DMA activity of the 16C32 (as 
described in a later section), it might be a good 
practice to include a few "No-ops" at this point. 
There should be enough NOPs to eliminate the 
case in which the DMA channel fetches the link 
address to the "end of list" entry from the pre- 
viously-last entry, before we store the new one in 
step 4, but then releases the bus for a while 
because of this throttling, before it fetches the 
zero byte count. 


Read the TDMR or RDMR and test the DMA 
channel's BUSY bit. If it's 0, the channel got to 
the end-of-list before our new link address could 
prevent this, and the channel must be restarted -- 
go to a routine that does this. If BUSY is still 1, 
the new buffer has been successfully added to the 
list and will be handled by the DMA channel. 


o> 


Fetching Transmit Control Blocks 


In Array and Linked-List modes, if software enables 
the Transmit Control Block feature of the serial 
controller (see DMA Support Features: Transmit 
Control Blocks in Chapter 4 for more information 
about this feature), the Transmit DMA channel can 
fetch the TCBs in two ways. 


The TCBinA/L bit in the Transmit DMA Mode Register 
(TDMR13) controls whether the channel fetches TCBs 
from Array and Linked List entries. This bit also 
controls the length of the entries. If TCBinA/L is 0, 
Array entries are 6 bytes long, Linked List entries are 
10 bytes long, and the channel handles TCBs the 
same way that it does in Single Buffer or Pipelined 
mode. That is, it fetches a 16- or 32-bit TCB from the 
data buffer just before it fetches the first character of 
each frame. In this case, the length of the TCB is 
included in the Byte Count of the buffer (but not in the 
length of the frame for the TCC). 


If TCBinAVL is 1, Array entries are 12 bytes long and 
Linked List entries are 16 bytes long. The channel 
fetches TCBs from array or list entries, other than the 
first entry, if the start of their buffers aligns with the 
start of a frame. For such entries, the channel fetches 
the two or four bytes of the TCB after it has read (and 
if the ClearCount bit is 1 written zero back to) the byte 
count in the array or list entry, and then reads and 
discards 2 or 4 bytes. For the first entry in the array 
or list after a Start or Start/Init command, and when 
advancing to a subsequent buffer within the same 
frame, the channel simply reads and discards the 6 
bytes that follow the byte count. 


Figure 58 shows two examples of TCBs with 
TCBinA/L=1. 


Array mode, with the first TCB in the Data Buffer 
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Linked List mode, software writes the first TCB to the TDR 
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Figure 58. Examples of Transmit Control Blocks with TCBinA/L=1 
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The length of a TCB in an Array/List entry is not 
included in the DMA channel's byte counts nor in the 
frame length values for the TCC. 


With either kind of TCB placement, the DMA and 
serial controllers operate fairly independently, without 
a lot of context-signalling between them, and it's 
important that software do what's needed to keep 
them co-ordinated and _ synchronized. These 
measures include: 

1. With TCBinA/L=0, allow 6 bytes for each array 
entry or 10 bytes for each list entry, place’‘a TCB 
of the length indicated by TxCtriBIk (CCR15-14) 
before the start of each frame, and include the 
length of TCBs in the byte counts of the buffers in 
which they're included. 


2. With TCBinA/L=1, allow 12 bytes for each array 
entry or 16 bytes for each list entry, and place a 
TCB in the 7th-8th or 7th-10th bytes of each entry 
after the first one, that starts a frame. (The 
16C32 ignores these locations in the first array or 
list entry, and in entries for subsequent buffers 
within a frame.) 

3. With TCBinA/L=1, either write the TCB for the first 
frame of an array or linked list directly to the 
Transmit Data Register before starting the 
Transmit DMA channel, or place the TCB for the 
first frame at the start of the first buffer and in- 
clude its length in the first buffer's byte count (as 
when TCBinA/L=0). 

4, With TCBinA/L=1, either ensure that a frame 
never starts in the middle of a buffer, or else place 
a TCB in the buffer before the start of each frame 
that does (as when TCBinA/L=0). In a Little- 
Endian system or with an 8-bit data bus, it's OK to 
use the Early Buffer Termination feature 
(described later) as a simple way to ensure that a 
frame never starts in the middle of a buffer. 


But for a 16-bit or wider bus in a Big Endian 
system, the DMA channel is only guaranteed to 
access the final byte of a frame correctly if 
software programs the Byte Count of the last 
buffer of the frame correctly, to match the TCC 
frame length. (In this case there's no reason to 
enable Early Termination.) 


Storing Receive Status Blocks 


Similarly, if software enables the Receive Status Block 
feature as described in Chapter 4, in Array or Linked 
List mode a Receive DMA channel can store RSBs in 
two ways. Figure 59 shows the two worthwhile cases 
of RSBs. 


If the RSBinA/L bit in the Receive DMA Mode 
Register (RDMR13) is 0, the channel handles RSBs 
as it does in Single Buffer and Pipelined modes. 


Array entries are 6 bytes long, Linked List entries are 
10 bytes long, and the channel stores the RSB after 
the last byte of each frame. In these cases, software 
should allow for the length of RSBs in the byte counts 
of the buffers in which they're stored. (RCC residual 
values never reflect RSB bytes.) 


But when RSB's are stored in the data buffers, soft- 
ware has to read the RCC FIFO to determine the 
length of each frame received, so that it can find the 
RSB's. (Because of this, there's no reason to ever 
use a 32-bit RSB in this mode.) Since the RCC FIFO 
is only four deep, software must read it in a reason- 
ably timely manner. In Array and Linked List modes, 
this software response requirement can be eased by 
programming 32-bit RSBs and the RSBinA/L bit 1. 


When RSBIinA/L is 1, Array entries are 12 bytes long,- 
Linked List entries are 16 bytes long, and the DMA 
channel stores an RSB in the (7th-8th or) 7th-10th 
bytes of the last array or list entry for each frame, 
after it has placed the last character of the frame in 
the buffer. When RSBinA/L is 1, software can ignore 
the RCC FIFO, and need not respond to IUSC 
interrupts as promptly. 


After the Rx DMA channel has stored the RSB in the 
array or list entry, it writes 2 (or 4) zero bytes to skip 
over that many "extra" bytes in the entry. These extra 
bytes maintain 32-bit-boundary alignment of the 
addresses in the array or list entries, as required by 
some processors. 


When RSBInA/L is 1, the length of the RSB is not 
included in either the DMA channel's byte counts nor 
in the RCC residual values. 


As on the Transmit side, software has to take certain 
steps to ensure that the Receiver and the DMA 
channel work together: 


1. With RSBinA/L=0, allow 6 bytes for each array 
entry or 10 bytes for each list entry, and allow for 
Receive Status Blocks in the byte counts of 
buffers in which they're stored. 

2. With RSBinA/L=0, read the RCC FIFO once for 
each frame and use these RCC residual values as 

described in Chapter 4, to determine the length of 
each frame. Knowing the frame lengths, software 
can then find the RSBs, which follow the last 
character of each frame. 

3. With RSBinA/L=1, always program the TermE bit 
in the Receive DMA Mode Register (RDMR9) to 1 
to enable the Early Buffer Termination feature. 

4. With RSBinA/L=1, allow 12 bytes for each array 
entry or 16 bytes for each list entry. The length of 
RSB's need not be included in buffer byte counts 
for the DMA channel, nor in a maximum frame 
length value for the RCC. 


A 16-bit RSB in the Data Buffer 
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Figure 59. Receive Status Blocks 


5. With RSBinA/L=1, the channel stores an RSB in 
the 7th-10th (or 7th-8th) bytes of the array or list 
entry for each buffer in which it stores a character 
marked with RxBound status. It zeroes these 
locations in array or list entries for preceding 
buffers within the same frame, that is, those that it 
fills before the frame ends. Thus, software can 
examine the RxBound bit of each entry that the 
DMA channel has finished with; those in which 
this bit is 1 represent buffers that include the end 
of a frame. 


On the Receive side, there are actually two internal 
termination signals that the serial controller asserts to 
the Receive DMA channel. [The DMA channel honors 
these signals only when its TermE bit (RDMR9) is 1.] 
The serial controller asserts one of these signals as 
the DMA channel takes a byte marked with RxBound 
status out of the RxFIFO. If software hasn't enabled 
the Receive Status Block (RSB) feature in the 
Channel Control Register (CCR7-6), the serial 
controller asserts the other signal at the same time, 
otherwise it asserts the other termination signal when 
the DMA channel stores the last of the two or four 
bytes of the RSB. If the DMA channel is in Array or 
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Linked List mode and has been programmed to store 
RSB's in the array or list, it uses the first signal to shift 
from storing in the data buffer to storing in the array or 
list, and uses the second signal to shift from storing in 
the array or list to fetching information for the next 
buffer. In all other modes, the channel simply uses 
the second signal to know when it has stored all the 
information for the current buffer. 


Channel Status 


The earlier Figure 52 shows the less significant byte 
of each DMA Mode Register (TDMR or RDMR), which 
contains eight bits indicating the status of that 
channel. A channel clears these bits to 0 in response 
to a hardware Reset or when software writes a Reset 
command to the DMA Command / Address Register 
(DCAR). All of them can be set and/or cleared by the 
DMA channel. Some of them are affected by 
commands other than Reset, and/or when software 
reads the (LSByte of the) register. 


Some of these bits exist solely for the information of 
host software. The DMA channel uses many of them 
as part of its internal state. 


The CONT bit (TDMR7/RDMR7) is used only in 
Pipelined mode. In this mode the IUSC sets it to 1 
when software writes a "Start/Continue This Channel" 
command to the MSByte of the DCAR. A channel 
checks CONT when it has decremented its Byte 
Count Register (TBCR or RBCR) to zero, or, if soft- 
ware has enabled early buffer termination, ifAwhen the 
serial controller signals for such a termination. _ If 
CONT is 0 at this time, the channel clears the BUSY 
bit (xDMRS5) and stops. Otherwise, the channel clears 
CONT to 0 and continues operating. It transfers the 
contents of its Next Address Register to its Address 
register (NTAR to TAR, or NRAR to RAR) and 
transfers the contents of its Next Byte Count Register 
to its Byte Count Register (NTBCR to TBCR, or 
NRBCR to RBCR). Then it resumes transferring 
serial data to or from the new buffer, as requested by 
the serial controller. 


Software may need to take special precautions to 
avoid issuing the "Start/Continue" command while the 
channel is testing the CONT bit, as described in the 
earlier section, Pipelined Mode. 


The GLink bit (TDMR6 or RDMR6) can only be 1 in 
Linked List mode, while the channel is reading the 
address of the next list entry from memory. GLink 
stays set if the channel clears BUSY (xDMR85) while 
reading the link address, because of a command or a 
hardware Abort. In this case software must clear 
GLink by issuing a "Reset This Channel" command 
before it restarts the channel. 


The BUSY bit (TDMR5 or RDMR8) is set to 1 by any 
of the Start commands, and remains 1 while the 
channel is still operating in response to the command. 
It is O if the channel has stopped and will need 
software attention (including another Start command) 
before it can resume operation. The channel sets 
BUSY when host software writes a Start, Start/Init, or 
Start/Continue command (for one or all channels) to 
the DCAR. The channel clears BUSY when one of 
the following occurs: 

1. ahardware Reset, 

2. a Reset, Pause, or Abort command, for this 
channel or all channels, 

if external hardware asserts the /ABORT pin low 
during a transfer by the channel, 

reading a zero byte count in Array or Linked List 
mode, 

decrementing the byte count (TBCR or RBCR) to 
zero in Single Buffer mode, 

if software has enabled early buffer termination in 
Single Buffer mode, and the serial channel signals 
for such a termination, or 

if the channel tests the CONT bit as zero in 
Pipelined mode, after it has decremented the Byte 
Count Register to zero, or, if software has 


3. 
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enabled early buffer termination, after the serial 
channel has signalled for such a termination. 


The INITG bit (TDMR4 or RDMR4) is used only in 
Array and Linked List modes. It indicates whether the 
channel is reading from the array or list. The channel 
sets InitG to 1 when software issues a Start/Init com- 
mand, and/or when the channel decrements its byte 
count (TBCR or RBCR) to zero, and/or if software has 
enabled the early termination feature and the serial 
controller signals for buffer termination. The channel 
clears INITG to O after it has read the address and 
byte count of the next buffer from memory. 


INITG stays set if a channel clears the BUSY bit while 
reading array or list information, due to a zero byte 
count or some other reason. In this case software 
should clear the bit using a "Reset This Channel’ 
command, before restarting the channel using a Start 
This Channel command. (There's no need to clear 
INITG before a Start/Init.) 


A channel sets the EOA/EOL bit (TDMR3 or RDMR3@; 
the name stands for End Of Array / End Of List) to 1 
in Array or Linked List mode, when it reads a zero 
byte count from the array or list in memory. A 
channel clears EOA/EOL to O in response to a 
hardware or software Reset, and when software reads 
the bit as 1. 


A channel sets the EOB bit (TDMR2 or RDMR2; the 
name stands for End Of Buffer) to 1 in any mode, 
when it decrements its Byte Count Register to zero. It 
also sets EOB if software has enabled the early 
termination feature and the serial controller signals for 
buffer termination. A channel clears EOB to 0 in 
response to a hardware or software Reset, and when 
software reads the bit as 1. 


A channel sets the HAbort bit (TDMR1 or RDMR1) to 
1 in any mode, when external hardware asserts the 
/ABORT pin low during a bus cycle by the channel. A 
channel clears HAbort to 0 in response to a hardware 
or software Reset, and when software reads the bit as 
a 


A channel sets the SAbort pin (TDMRO or RDMRO) to 
1 in any mode, when host software writes an Abort 
command for this channel (or all channels) to the 
DCAR. Achannel clears SAbort to 0 in response to a 
hardware or software Reset, and when software reads 
itas 1. 


Chapter 6 describes how each of the EOA/EOL, EOB, 
HAbort, and SAbort bits has a corresponding Interrupt 
Arm (IA) bit in the channel's DMA Interrupt Arm 
Register (TDIAR or RDIAR). If a_ status bit's 
corresponding IA bit is 1, the IUSC can request an 
interrupt when the channel sets the status bit to 1. 


Since the channel clears the EOA/EOL, EOB, HAbort, 
and SAbort bits each time software reads the LSByte 
of its Channel Mode Register, software should take 
care when reading this register so that important 
events are not inadvertently lost. Specifically, any 
time software reads the LSByte of TDMR or RDMR,, it 
should check and handle any and all of these four 
conditions/bits that are possible and significant. 


Commands and /BUSREQ Enable 


The DMA Command / Address Register (DCAR), 
shown in Figure 60, is a "shareable register", meaning 
that there's only one DCAR and that its contents apply 
to both of the IUSC's DMA channels. 


Software can use the LSByte of the DCAR for indirect 
register addressing, as described in Chapter 3, and 
can write commands for the DMA channels to the 
MSByte. Such commands can be directed to a 
specific channel or to all channels. The MSByte also 
contains one bit that enables or disables all operation 
of the DMA channels, by allowing or blocking 
assertion of the [USC's /BUSREQ output. 


The MSByte of the DCAR can be viewed as including 
a four-bit DCmd field in DCAR15-12 and a Channel 
Select bit in DCAR9. For commands that affect one 
channel, the latter bit selects whether the command is 
for the Transmit or Receive channel. For other com- 
mands the IUSC ignores the Channel Select bit. 
Since there are only two channels and only six 
channel-specific commands, it is probably simpler to 
regard DCAR15-9 as a 7-bit field encoded as follows: 


DCAR15-9 Command 


0000000 Null (no operation) 
0001000 Reset Tx Channel 

0001001 Reset Rx Channel 

0010000 Start Tx Channel 

0010001 Start Rx Channel 

0011000 Start/Continue Tx Channel 
0011001 Start/Continue Rx Channel 
0100000 Pause Tx Channel 

0100001 Pause Rx Channel 

0101000 Abort Tx Channel 

0101001 Abort Rx Channel 

0111000 Start/Init Tx Channel 
0111001 Start/Init Rx Channel 
1000000 Reset Highest IUS 

1001000 Reset All Channels 
1010000 Start All Channels 


1011000 Start/Continue All Channels 
1100000 Pause All Channels 

1101000 Abort All Channels 

1111000 Start/Init All Channels 


Other combinations of the DCAR15-9 bits are 
reserved by Zilog and should not be written to the 
DCAR. 


The Master Bus Request Enable bit (MBRE/DCAR8) 
controls whether the DMA channels can assert the 
/BUSREQ output to request control of the external 
bus from the host processor or central arbiter. 
Carrying the integration of the MSByte value one step 
further, note that the IUSC always captures a new 
state for MBRE whenever software writes the MSByte 
of DCAR. Note also that there is a strong link 
between certain commands and a particular state of 
MBRE. The following table gives typical full-byte 
hexadecimal values that can be written to the MSByte 
of DCAR to accomplish various operations. For 
commands that deactivate one channel, the table 
includes two values. The first applies to full-duplex 
operation in which the two channels operate indepen- 
dently, while the second applies to half-duplex oper- 
ation in which only one channel is active at a time. 


DCAR15-8 Operation 
00 Disable /BUSREQ (no other 
effect on the Channels) 
O1 Enable /BUSREQ (no other 


effect on the Channels) 


11/10 Reset Tx Channel 
13/12 Reset Rx Channel 
21 Start Tx Channel 
23 Start Rx Channel 
31 Start/Continue Tx Channel 
33 Start/Continue Rx Channel 
41/40 Pause Tx Channel 
43/42 Pause Rx Channel 
51/50 Abort Tx Channel 
53/52 Abort Rx Channel 
71 Start/Init Tx Channel 
73 Start/Init Rx Channel 
81 Reset Highest DMA IUS (enable 
/BUSREQ) 
90 Reset All Channels 
Al Start All Channels 
Bl Start/Continue All Channels 
CO Pause All Channels 
DO Abort All Channels 
Fl Start/Init All Channels 


15 14 13 12 


11 10 9 8 7 6 


5 4 3 2 1 0 


Figure 60. The DMA Command /Address Register (DCAR) 


A Reset command to a channel clears all the status 
bits in the LSByte of its DMA Mode Register, including 
BUSY, thus disabling the channel. It also clears the 
register bits associated with interrupts from the 
channel, namely the IE, IP, and IUS bits, as described 
in Chapter 6. 


A Start command to a channel sets the BUSY bit 
(xDMR85), which enables the DMA channel to operate 
when the Transmitter requests that its FIFO be filled, 
or when the Receiver requests that its FIFO be 
emptied. A Start command can be used to initially 
start up a channel, or to restart one after a Pause 
command. 


The Start/Continue command operates identically to 
Start in Single Buffer, Array, and Linked List Modes. 
In Pipelined mode, it sets both the BUSY and CONT 
bits (<DMR7 and 5), so that after the buffer described 
by the xAR and xBCR, the channel goes on to 
another buffer that's described by NxAR and NxBCR. 
The channel does this by transferring the contents of 
NxAR to xAR, transferring the contents of NxBCR to 
xBCR, and clearing CONT but keeping BUSY set. 


In Pipelined mode, software can use this command to 
start up a channel, after writing the xAR, xBCR, 
NxAR, and NxBCR, or to provide a subsequent buffer 
to a channel after writing just NxAR and NxBCR. In 
the latter case, software may need to take special 
precautions to avoid issuing the Start/Continue com- 
mand while the channel is testing the CONT bit, as 
described in the earlier section, Pipelined Mode. 


The Start/Init command operates identically to Start 
in Single Buffer and Pipelined modes. In Array and 
Linked List modes, Start/Init sets both the BUSY and 
INITG bits (xDMR5 and 4), so that the channel starts 
by loading the address and length of the initial buffer 
from the first entry in the array or list. Thereafter the 
channel transfers data as requested by the 
Transmitter or Receiver based on its FIFO status, just 
as for a Start command. Start/Init is intended only for 
starting an inactive channel in a new buffer. 


A Pause command to a channel clears the BUSY bit 
(xDMRS5), making the channel inactive until software 
restarts it by means of a Start command. 


An Abort command to a channel similarly clears 
BUSY (xDMRS5), but it also sets the SAbort bit 
(xDMRO), which can cause an interrupt if enabled. 
Software can use this command (instead of Pause) to 


stop a DMA channel when the channel will not be 
restarted to continue operation in the current buffer. 


The Reset Highest DMA IUS command clears the 
IUS bit of the highest priority DMA channel that has 
the bit set (if any). See Chapter 6 for complete infor- 
mation on IUSC interrupt facilities. 


Address Sequencing 


The AddrMode field of each DMA Mode Register 
(TOMR11-10 and RDMR11-10) controls how the 
channel sequences the buffer address from one data 
cycle to the next: 


AddrMode Address Sequencing 
00 the channel increments xAR 
01 the channel decrements xAR 
10 xAR stays the same 
ll Reserved; do not program 


The "increment" mode is the most commonly used. 
The "decrement" mode is included primarily to match 
the capabilities of other DMA channels that were used 
for applications such as magnetic tape that could be 
read backward. The "fixed" mode is useful to transfer 
data to and from external FIFO devices, although the 
only handshaking provided for such applications is via 
the /WAIT//RDY line. 


Figure 61 shows the shareable DMA Control Register 
(DCR), the fields of which may affect one or both 
DMA channels. Its AddrSeg field (DCR1-0) controls 
how far the DMA channels will propagate a carry 


when incrementing or decrementing a memory 
address: 
AddrSeg Address Incer/Decr Range 


00 All 32 bits are affected 

01 Reserved: do not program 

10 The LS 16 bits are affected; 
A31-16 are fixed 

11 The LS 24 bits are affected; 
A31-24 are fixed 


This field applies to the incrementing and decre- 
menting of addresses in data buffers and, for the 
Array and Linked List modes, to the incrementing of 
addresses while reading from arrays and lists. It 
applies to both the receive and transmit channels. In 
the latter two cases, if a channel attempts to incre- 
ment or decrement an address over the implied 
boundary, the address instead wraps around to the 
opposite end of the same 64 KByte block (for 10) or 
the same 16 MByte block (for 11). 


[omen | ALBVO;! ReArbTime Reserved (0) Reserved (0) | Safe AddrSeg 


” Figure 61. The DMA conta Reciitak (OCR) 


Binary Format in Arrays and Lists 


In Array and Linked List modes the |USC DMA chan- 
nels can fetch addresses and byte counts from 
memory in either of the two ways that different micro- 
processors may store them. The ALBVO bit in the 
DMA Control Register (DCR12; the name stands for 
Array/List Binary Value Order) controls how the DMA 
channels fetch binary values from memory. If ALBVO 
is O, they fetch the less-significant portions of binary 
values from lower-addressed memory locations, which 
is compatible with the Zilog Z80 and most Intel 
processors. If ALBVO is 1, the channels fetch the 
more-significant portions of binary values from lower- 
addressed locations, which is compatible with the 
Zilog Z8000 and most Motorola processors. The 
channel fetches these values using 16-bit transfers if 
16Bit (BCR2) is 1 and 8/16 (TDMR8 or RDMR8) is 0, 
or using 8-bit transfers if 16Bit is O and/or 8/16 is 1. 
Figure 62 shows how the IUSC expects the 32-bit 
addresses and 16-bit counts to appear on the AD pins 
for the various ALBVO options, data widths, and TCB/ 
RSB locations. 


Conditions for DMA Operation 


Several conditions must be met before the IUSC will 
request use of the host bus and then operate as a 
DMA bus master: 

1. The Master Bus Request Enable bit (MBRE) in 
the DMA Command / Address Register (DCAR8) 
must be 1, and 

the BUSY bit (xDMRS) of one or both of the DMA 
channels must be set due to a Start command, 
and 

the Receiver or Transmitter, associated with a 
Busy channel, must be requesting DMA transfer, 
OR, a Busy channel must be in Array or Linked 
List mode with its INITG bit (xDMR4) set, either 
because of a Start/Init command or because of 
the termination of the previous buffer, and 

the BRQTP bit in the Bus Configuration Register 
(BCRS) must be 1, indicating that this IUSC 
should drive the /BUSREQ signal full-time, OR 
/BUSREQ must be high, and 

the minimum time between bus requests must 
have elapsed. The MinOffs9 bit (ODCR5) controls 
the exact minimum time. 


Once the IUSC has driven /BUSREQ low because 
these conditions are met, it continues to do so until 
one of the following occurs: 


3a. 


3b. 


4a. 


4b. 


a. the duration of this period of bus mastership 
exceeds either of the two programmable limits in 
the Burst/Dwell Control Register (BDCR), or 

b. one channel runs out of things to do, for example, 


because the serial controller negates its request 
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because the TxFIFO becomes full or the RxFIFO 
becomes empty, and the other channel isn't 
requesting to use the bus, or 


c. achannel clears its BUSY bit, for any of the 
reasons given in an earlier section, and the other 
channel isn't requesting to use the bus, or 

d. software clears MBRE to 0, or 

e. the external hardware negates the /BIN input after 


asserting it for at least three CLK cycles in 
response to this bus request. 


The following sections cover various aspects of the 
conditions described above. 


DMA Requests by the Receiver and 
Transmitter 


Aside from fetching addresses and counts from array 
and linked lists, the IUSC's DMA channels will only 
transfer data when the serial controller requests that 
they do so. 


The Transmitter asserts its internal DMA Request to 

the transmit channel as follows: 

1. when the Transmitter isn't "holding between 
frames", from the time the number of empty 
character positions in the TxFIFO exceeds the 
Transmit OMA Request Level value (TICR15-8 
after a "Select TICRHi=/TXREQ Level" command), 
until 
a. the TxFIFO is filled, or 
b. the Transmit Character Counter counts down 

to zero, indicating the end of a message or 
frame and 


i, the Transmit Control Block feature is enabled 
and/or 


li. the Wait4TxTrig bit (CCR13) is 1. 


from the time software writes a Trigger Channel 
Load DMA command to the Channel Command / 
Address register (CCAR), until a DMA transfer 
into CCAR clears the ChanLoad bit (CCAR7). 


Each of 1.b.i and 1.b.ii establishes a separate “holding 
between frames" state for the Transmitter. The 
Transmitter clears the former one automatically, when 
it finishes sending the frame. Software must clear the 
latter one, by issuing a "Trigger Tx DMA" command to 
the RTCmd field of the Channel Command / Address 
Register (CCAR15-11). 


Point 1.b.i reflects the fact that, when Transmit 
Control Blocks are enabled, the Transmitter stops 
requesting further DMA transfers after the Transmit 
DMA channel fetches the last character of one frame, 
until it has sent that character and terminated the 
frame or message. The Transmitter does this so that 
the loading of the TCB information for a new frame 
doesn't affect sending the end of the preceding frame. 


ALBVO (DCR12) = 0 (little-endian) ALBVO (DCR12) = 1 (big-endian) 


































































16BIT (BCR2) = 1 and 8/16 (xDMR8) = 0 16BIT (BCR2) = 1 and 8/16 (xDMR8) = 0 
TCBinA/L or RSBinA/L (xDMR13) = 0 TCBinA/L or RSBinA/L (xDMR13) = 0 
Address AD15 ADO Address AD15 ADO 

N N 
Ne2 N42 
N+4 Ned 
N+6 N+6 
N+ N+ 
ALBVO (DCR12) = 0 (little-endian) ALBVO (DCR12) = 1 (big-endian) 
16BIT (BCR2) = 0 and/or 8/16 (xDMR8) = 1 16BIT (BCR2) = 0 and/or 8/16 (xDMR8) = 1 
TCBInA/L or RSBinA/L (xDMR13) = 0 TCBinA/L or RSBinA/L (xDMR13) = 0 
Address AD15/7 AD8/0 Address AD15 AD8/0 
N N 
Ne Net 
N+2 N+2 
N+3 N+3 
Ne4 N+4 
N+5 N+5 
N46 N+6 
N47 N47 
Ns8 N+8 
N+9 | Next/Link Address 31-24 N+9 
ALBVO (DCR12) = 0 (little-endian) ALBVO (DCR12) = 1 (big-endian) 
16BIT (BCR2) = 1 and 8/16 (xDMR8) = 0 16BIT (BCR2) = 1 and 8/16 (xDMR8) = 0 
TCBinA/L or RSBinA/L (xDMR13) = 1 TCBinA/L or RSBinA/L (xDMR13) = 1 
Address AD15 ADO Address AD15 ADO 
N N 
N+2 N+2 
N+4 N+4 
N46 N+6 
N+8 N+8 
N+10 N+10 not used 
N+12 N+12 
N+14 N+14 
ALBVO (DCR12) = 0 (little-endian) ALBVO (DCR12) = 1 (big-endian) 
16BIT (BCR2) = 0 and/or 8/16 (xDMR8) = 1 16BIT (BCR2) = 0 and/or 8/16 (xDMR8) = 1 
TCBinA/L or RSBinA/L (xDMR13) = 1 TCBinA/L or RSBinA/L (xDMR13) = 1 
Address AD15/7 AD8/0 Address AD15/7 AD8/0 
N N 
N+ Ne 
N42 N42 
N+3 N+3 
N+4 N+4 | 
N+5 N+5 
N46 N46 
N47 N+7 
N+8 N+8 
N+o N49 
N+10 N+10 
N+11 Nett 
N+12 N+12 
N+13 N+13 
N+14 N+14 
N+15 Next/Link Address 31-24 N+15 Next/Link Address 7-0 





Figure 62. The Order of Binary Values in Arrays and Linked Lists 
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When the Receiver isn't "holding between frames", it 
asserts the internal DMA Request to the receive 
channel in two situations: 


A. from the time the number of received characters 
in the RxFIFO exceeds the Receive DMA Request 
Level value (RICR15-8 after a "Select RICRHi= 
/RxREQ Level" commana), until the channel 
empties the RxFIFO, or 


in HDLC/SDLC, Ethernet/802.3, Transparent 
Bisync, or 1553B mode, from the time that the 
Receiver places a byte marked with RxBound 
status into the RxFIFO, until the channel has read 
out the RxBound character. (Such RxBound 
status signifies the last character of each frame or 
message in HDLC, Ethernet, and Transparent 
Bisyne mode, and the second or only character of 
each word in ACV/1553B mode.) 


If the software has enabled Receive Status 
Blocks, the Receiver keeps its request asserted 
while the DMA channel stores the status block in 
memory. Also, if the number of characters left in 
the RxFIFO, after the DMA channel has read out 
the RxBound character, still exceeds the Receive 
DMA Request Level, the channel keeps asserting 
its request per condition A. 


Note that, if the Wait4RxTrig bit in the Channel 
Control Register (CCR4) is 1, then after the Receive 
DMA channel writes a character marked with 
RxBound status into memory (plus the Receive Status 
Block if this feature is enabled), the Receiver enters 
the "holding between frames" state. In this state, it 
doesn't request any more DMA transfers until after 
software writes a "Trigger Rx DMA" command to the 
RTCmd field of the Channel Command/Address 
Register (CCAR15-11). This interlock overrides 
points A and B above. 


The Receive Character Counter feature cannot force 
the internal DMA Request nor early buffer termination. 


Programming the DMA Request Levels 


As noted in other chapters, the MSBytes of the Trans- 
mit and Receive Interrupt Control Register (TICR and 
RICR) may each represent any of several registers. 
The content of each MSByte depends on which of 
several selection commands was most recently writ- 
ten to the Transmit or Receive Command Status Reg- 
ister (TCSR or RCSR), respectively. The selections 
for the Transmitter and Receiver are independent. 


To program or read back a DMA Request Level, soft- 
ware must first write the "Select RICRHi=/RxREQ 
Level" or "Select TICRHi=/TXREQ Level" command 
(0111) to the TCmd or RCmd field of the Transmit or 
Receive Command / Status Register (TCSR15-12 or 
RCSR15-12). This step can be omitted if it's known 
that none of the commands 0100-0110 have been 
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written to TCSR or RCSR since the last time 0111 
was written there. The DMA Request Level value can 
then be read or written as the MSByte of the TICR or 
RICR. 


The Transmit DMA Request Level should be pro- 
grammed with 1 less than the number of empty 
TxFIFO positions, at which the Transmitter should 
start asserting its internal Request to the Transmit 
DMA channel. The Receive DMA Request Threshold 
should be programmed with 1 less than the number of 
received characters in the RxFIFO, at which the 
Receiver should start asserting its internal Request to 
the Receive DMA channel. For example, if the 
Receiver should request DMA operation when its 32- 
byte RxFIFO is 3/4 full, software should write hex 70 
to RCSR15-8 to select the DMA threshold as RICR15- 
8, and then write decimal 23 (hex 17) to RICR15-8. 


Note that a Purge Tx FIFO (or Purge Rx and Tx FIFO) 
command can make a channel immediately assert 
/TxREQ. 


Inter-Channel Operation and Priority 
lf/when both DMA channels are active, three fields in 
the DMA Control Register (DCR) control how they 
share use of the external bus. 


The ChanPri field (DCR15-14) selects the relative pri- 
ority of the two channels for use of the bus, that is, 
which one gets to use the bus first if both are 
requesting at the time of a bus grant: 

ery Channel Priority 


Transmit channel has priority 


i Receive channel has priority 

10 Alternating: whichever 
channel uses the bus first in 
one bus grant, has the lower 
priority in the next one. 

11 Reserved; do not program 


The PreEmpt bit (DCR13) selects whether the higher- 
priority channel (as defined by the ChanPri field) can 
take over control of the bus if it starts requesting con- 
trol while the lower-priority one is using the bus. If 
PreEmpt is 0, once a channel starts using the bus it 
continues to do so until one of four events occurs: 


1. it fills or empties its FIFO, or 


2. it reaches the time limit for use of the bus, or 
3. it clears its BUSY bit, or 
4. software clears MBRE. 


If PreEmpt is 1, the lower-priority channel relinquishes 
bus control to the higher one, after it completes any 
bus cycle that was in progress when the higher- 
priority channel started requesting. 


When PreEmpt is 0, the ReArbTime field (ODCR11-10) 
determines when the IUSC reselects which channel is 
using the bus: 

ReArbTime Channel Re-arbitration Time 

00 The IUSC reselects the active 
channel at the start of each 
bus grant, and one channel 
can use the bus after the 
other within the same period 
of bus control. 

01 Once a DMA channel has 
started using the bus, it 
continues to do so until its 
part of the serial controller 
request has released its 
request, even if this takes 
several periods of bus 
control. However, once this 
occurs, the other channel can 
use this bus for the duration 
of the same period of bus 
control. 

10 The IUSC reselects the active 
channel only at the start of 
each bus grant; only one 
channel uses the bus per 
period of bus control. 

11 Reserved; do not program 


When PreEmpt is 1, ReArbTime should be program- 
med as 00. In particular, do not program PreEmpt=1 
and ReArbTime=10. This combination results in a 
mode in which, if preemption has occurred and the 
higher-priority channel runs out of things to do, the 
IUSC stays on the bus until one of the duration limits 


/AS. RW, 
/RD, WR, ete. 


is reached, without letting the lower-priority channel 
use the bus! 


Bus Acquisition and Release Timing 


Figure 63 shows typical bus acquisition and release 
sequences. If the IUSC is asserting /BUSREQ when it 
first samples /BIN low at a rising edge of CLK, it starts 
preparing to take control of the bus, otherwise it drives 
/BOUT low. Two CLK cycles after first sampling /BIN 
low with /BUSREQ low, the IUSC samples /BIN again. 
If /BIN is still low, then from the next rising edge the 
IUSC places the more-significant half of the initial 
memory address on the AD lines, and starts driving 
/UAS, /AS, /DS, R//W, /RD, /WR, plus S//D and D//C if 
the DCSDOut bit in the DMA Control Register (DCR4) 
is 1. From the next rising edge of CLK, it drives /UAS 
to low. There is one more CLK period of address 
setup between the AD lines and the first rising edge of 
/UAS after bus acquisition, than there is for 
subsequent /UAS pulses (if any) within the same 
period of bus control. 


The IUSC will release control of the bus if the bus 
grant on /BIN goes false/high while it's using the bus. 
A following section, Master Bus Cycles, shows the 
timing for the withdrawal of /BIN. 


Typically, the IUSC makes the decision to release the 
bus during a bus cycle, which is the case shown in the 
latter part of Figure 63. It drives or releases 
/BUSREQ to high from the rising CLK edge that is 4.5 
CLK periods after the falling edge from which it drives 
/DS and (/RD or /WR) to high. It also releases the 
/UAS, /AS, /DS, R/MW, /RD, and /WR lines, and if 
necessary the AD lines, S//D, and D//C, from the 
same rising edge. 





Figure 63. Bus Acquisition and Release 
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lf the IUSC makes the decision to release the bus 
later than is needed to achieve the timing shown in 
Figure 63, it still drives or releases /BUSREQ to high 
from the same rising edge on CLK at which it releases 
the various other bus signals. 


Bus Cycle Options 


Three bits in the shareable DMA Control Register 
(DCR; see Figure 61) affect how the DMA channels 
operate as bus masters -- that is, how they act once 
they have control of the bus. This information is pre- 
sented both here and in Chapter 2, Bus Interfacing. 


D//C, S//D Status Output 


The DCSDOut bit (DCR4) controls whether the IUSC 
drives the D//C and S//D pins when it is the bus 
master. If DCSDOut is 1, the IUSC drives D//C Low 
for Transmit channel operations and High for Receive 
channel cycles, and drives S//D High during transfers 
of serial data and Low for array or linked-list fetching. 
When this bit is 1, external drivers for D//C and S//D 
must be 3-stated (released) when the IUSC has 
control of the bus, that is, when the /BIN pin is low. 


If external logic has no use for the above information, 
software can program DCSDOut as 0, in which case 
the IUSC never drives D//C and S//D, This means 
that the host processor or bus interface can drive 
these pins full-time. 


Wait Insertion 


If the 1Wait bit (DCR3) is 1, the IUSC extends the 
data portion of each master bus cycle by 1 CLK 
period. This allows use of slower memories for a 
given CLK frequency, or use of a faster CLK 
frequency with a particular memory type. Signalling 
on /WAIT//RDY can be used to extend master bus 
cycles regardless of the state of this bit. When 1Wait 
is 1 the IUSC starts actively sampling /WAIT//RDY 
one CLK period later than when it's 0. 


/UAS Frequency 


Since the DMA channels maintain 32-bit addresses 
but have only a 16-bit external bus, they present each 
address in two parts. They signal the availability of 
the more significant half of an address with a strobe 
on the /UAS pin, and signal the LS half of each 
address with a strobe on /AS. The UASAII bit (DCR2) 
controls how often the channels present the more- 
significant half of the address. If UASAII is 1, every 
master bus cycle includes presentation of the more- 
significant half of the address on the AD15-0 pins, 
with a low-going pulse on /UAS. This means that 
every bus cycle takes at least 4 cycles of CLK. 
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If UASAIl is 0, the IUSC includes a /UAS sequence 

only in cycles that meet one or more of the following 

criteria: 

1. inthe first cycle after taking control of the bus 
from another master, 


2. in the first cycle after switching from one channel 
to the other, 

3. in Pipelined mode, in the first cycle after switching 
from one buffer to the next, 

4. in Array or Linked List mode, in every cycle that 
accesses the array or list, 

5. in Array or Linked List mode, in the first data cycle 
after fetching from the array or list, or 

6. inthe first cycle after incrementing a buffer 


address results in a carry out from A15, even if 
the AddrSeg field (DCR1-0) is 10 so that the carry 
is blocked. 


When the IUSC includes a /UAS sequence in a bus 
cycle, the cycle is at least 4 CLK periods long, while if 
it doesn't, the bus cycle can be as short as 3 CLKs. 


UASAII should be programmed as 1 only if 
required by unusual external hardware. For 
example, if the IUSC and another bus master share 
an upper-address latch and the other bus master can 
insert cycles between IUSC cycles within the same 
bus grant, UASAII would want to be 1. 


Master Bus Cycles 


Figures 64 and 65 show DMA Read and Write cycles 
with the IUSC as bus master and the UASAII bit 
(DCR2) set to 0. In each case two cycles are shown. 
The first includes a /UAS strobe and is four CLK 
periods long. The second does not include a /UAS 
and is three CLK periods long. In both cases, to 
achieve these minimum bus-cycle times, the /WAIT/ 
/RDY signal should setup and hold in the "ready" 
state, around the falling edge of CLK that follows the 
rising edge of /AS. As noted in the preceding section, 
if the 1Wait bit in the DMA Control Register (DCRS) is 
1, the IUSC delays its first sampling of (WAIT/RDY by 
one CLK period. In this case, bus cycles that include 
a /UAS strobe are at least five CLK periods long, and 
those that don't are at least four CLKs long. For each 
falling edge of CLK at which the IUSC samples 
MWAIT//RDY as "Not Ready", it extends the length of 
the cycle by one CLK period. 


As shown in the Figures, the "ready" state is High for 
"Wait" signalling and Low for "Acknowledge" signal- 
ling. The kind of signalling on /WAIT//RDY depends 
on whether the S//D pin was High or Low at the time 
that software wrote the Bus Configuration Register 
(BCR) after the last Reset. 


| | "| —-" 
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| | | ! 
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Rw | | = 
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MWAIT//RDY ry | 
(as Wait) | | | | 
NVAIT//RDY ane i | TO | ee 
(as Ack) , 
/ABORT \ \ 
| 
/BIN | | | 


Figure 64. Master Read Cycles 
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NWAIT//RDY 
(as Wait) | | , | 


/WAIT//RDY 
(as Ack) 


/BIN 


Figure 65. Master Write Cycles 
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Note also that in DMA Read operations, read data 
from memory should set up and hold around the rising 
edge of the /DS and /RD lines. This gives the 
memory subsystem some extra access time as com- 
pared to having to set up to the falling CLK edge from 
which the IUSC drives /DS and /RD to high, but this 
characteristic must be considered in the memory 
design and the /WAIT//RDY logic. 


Given that the Figures assume the UASAII bit (DCR2) 
is O, the "possibly low" states at start of the /DS and 
/RD or /WR traces in the Figures illustrate the inter- 
cycle timing when there is a carry out of A15 during 
address incrementing (that is, when address "X" has 
16 low-order zeroes). When UASAII is 0, this is the 
only case in which a cycle that includes a /UAS will 
directly follow another cycle. The other occasions that 
force a /UAS strobe in the middle of a period of bus 
control all involve several CLK period delays for inter- 
nal "nousekeeping" functions, between the preceding 
cycle and the cycle that includes the /UAS, as follows: 


Condition forcing /UAS: # of extra CLK periods 











before the /UAS cycle 
Inter-channel switch 
Pipelined mode 
buffer switch 
Serial Data Transfer 
to Array or List Fetch 
Array or List Fetch to 
Serial Data Transfer 









(All of the values above are in addition to the one CLK 
cycle needed for the /UAS sequence itself.) 


The last two signals in Figures 64 and 65 illustrate the 
timing of the /ABORT and /BIN inputs. Both inputs 
are effective at the rising edge of CLK that immedi- 
ately precedes the falling edge of CLK at which the 
I|USC samples /WAIT//RDY "ready". If DMA operation 
is to be aborted after the bus cycle shown for 
“address X+1 or 2", then /ABORT must set up and 
hold Low around that edge. To force the IUSC to give 
up bus control after the bus cycle shown for "address 
X+1 or 2", /BIN must set up High to that edge. 


Bus Occupancy Throttling 


In some systems it may be necessary or desirable to 
limit the IUSC's use of the host bus. For example, in 
a dedicated control system it may be necessary to 
guarantee a maximum interrupt response time, and 
l\USC DMA activity may be a factor in the interrupt 


response time of the host processor. As well as 
responding to an external withdrawal of its bus grant 
as described in the preceding section, the IUSC 
allows its DMA activity to be programmatically limited. 
This can be done in terms of the maximum duration 
that the part will use the bus for each bus grant. Bus 
activity can also be limited in terms of the minimum 
time that the IUSC will stay off the bus before 
requesting it again. 


The MinOff39 bit in the DMA Control Register (DCRS5) _ 
controls the minimum time for which the IUSC will 
keep /BUSREQ inactive/high. If MinOff39 is 0, this 
minimum is 7 CLK periods, while if MinOff39 is 1, the 
IUSC will not "rerequest" the bus for at least 39 CLKs. 


The shareable Burst/Dwell Control Register (BDCR) 
controls the maximum duration for which the IUSC will 
use the bus, per bus grant. Figure 66 shows the 
BDCR. If the MaxXfers field (BDCR15-8) is non-zero, 
the IUSC treats its contents as the largest number of 
bus transactions it will do in response to one bus 
grant. If the MaxCLKs field (BDCR7-0) is non-zero, 
the IUSC will use the bus for up to 8 times that 
number of CLK periods, in response to each grant. If 
both values are zero (as they are after Reset), for 
each bus grant the IUSC will use the bus until it runs 
out of things to do, e.g., until the RxFIFO is empty 
and/or the TxFIFO is full. If both values are non-zero, 
the IUSC limits its bus usage according to whichever 
one expires first. 


Reaching one of these limits never terminates a cycle 
in progress; a limit takes effect only after a cycle is 
over. If a timeout on the length of a cycle is desired, 
for example to detect an access to a non-existent 
memory address, it must be implemented externally 
using the /ABORT pin. 


Array and Linked List Fetching Status 


In Array and Linked List modes, the INITG and GLink 
bits in the TDMR or RDMR provide a first level of 
information by which software can read the state of a 
channel that is fetching information from an array or 
linked list. More detailed status about array and 
linked-list fetching is available in the shareable DMA 
Array Count Register (DACR). Figure 67 shows the 
DACR, which contains separate RALCnt and TALCnt 
fields (DACR7-4 and DACR3-0 respectively) for the 
two channels. These fields are 1 bit wider than on the 
16C31 because the DMA channels need more states 
to implement the 16C32's new features. 


15 14 13 12 11 10 9 8 


a: 6 5 4 3 2 1 0 


Figure 66. The Burst/Dwell Control Register (BDCR) 
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The DMA channels sequence these fields from all 8/16 (TDMR8 or RDMR8) is 0. If 16Bit=0 and/or 
ones downward as they go through the steps of 8/16=1, the channel will use 8 bit transfers and will 
fetching array and list entries and transferring data to = thus go through more states. 


or from the buffers that the entries describe. The TCBinA/L (TDMR13), RSBinA/L (RDMR13), and 
In Linked List mode a channel sequences TALCnt or ClearCount (TDMR12 or RDMR12) bits also affect the 
RALCnt with GLink=0 while fetching the buffer ad- state sequence that the DMA channels follow and 
dress and count, and then goes through further states showin TALCnt and RALCnrt. 

with GUink=1 while fetching the next entry address. Table 3 shows all the values that TALCnt and RALCnt 


A 16C32 DMA channel will use 16-bit transfers to | can assume, and their meaning, with notes indicating 
access the array or linked-list if 16Bit (BCR2) is 1 and —_in which contexts each state can occur. 


Reserved (0) RALCnt TALCnt 
3 2 1 0 


15 14 13 12 11 10 9 8 7 6 5 4 
Figure 67. The DMA Array Count Register (DACR) 


This State Can Occur For: 
NITG/GLink| TALCnt| State of the Channel Data = Clear | TCBinA/L 
RALCnt Width ount |RSBinA/L 


0000 | Single Buffer or Pipelined mode 


Array fetch pending, 
1111 | First list fetch pending, or 
Link Address fetched , 












O 


=) 
if 


co 
~— 
_~ 
E 





0/1 





CO 
~— 
—_. 
o> 





0/1 


—_—s 
ss 
oO 
—_, 
— 
n 
- 
a 
2. 
—h 
Oo 
—h 
188) 
Cc 
= 
@ 
_ 
> 
Q. 
Q. 
om 3 
@ 
wn 
” 
—n 
@O 
rc 
oO 
a 
@ 
jor 
@ 
~~ 
a © 
— | — 
ak | oe | —_ sad) 


—k, 
[@) 
ss 
ss 
108) 
Cc 
= 
oO 
~ 
> 
Q. 
QO 
=x 
© 
”n 
n 
—* 
oO 
-- 
QO 
a 
4?) 
Qa 
© 
— 
oi, 
oO) 
© 
™_ 
—_ 


—_ 
Oo 
oO 
a 
168) 
tom a 
oO 
© 
oO 
Cc 
me} 
we 
—h 
@O 
a> 
QO 
— 
@O 
Q. 
(oe) 
— 
pa 
sl 


0/1 


—. 
Oo 
Oo 
—h 
J 
@ 
oO 
Q. 
= 
= | 
Co} 
= 
-— 
oO 
Qa 
pad) 
ae a 
pad) 
oO 
Cc 
= 
@ 
a 
oO 
= 
© 
— 
—_ 
Oo) 





0/1 


© 
—. 
— 
gle 


0111 | Byte Count cleared to zero 
O14 Receiving into data buffer, or 


Transmitting from data buffer 
0110 1st byte of TCB fetched, or 
1st byte of RSB (or zero) stored 
TCB control word fetched, or 
0101 RSB status word (or zero) stored 8/16 


0100 3rd byte of TCB fetched (ignored if 16 bit TCB) or 
3rd byte of RSB (or zero) stored 


RCC residual (or zero) stored _ 
11th byte of entry read/ignored (Tx), or 
11th byte of entry cleared to zero (Rx 
6th word of entry read/ignored (Tx), or 
6th word of entry cleared to zero (Rx 


1101 | 1st half of Link Address fetched 
1 1100 | 3rd byte of Link Address fetched 


Table 3. States of a DMA Channel 
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6. Interrupts 


The interrupt subsystem of the IUSC derives from 
Zilog's long experience in providing the most 
advanced interrupt capabilities in the microprocessor 
field. These capabilities can be used to their best 
advantage in a system including a Zilog processor and 
other Zilog peripherals, but it's easy to interface the 
IUSC to interrupt other processors as well. This 
chapter describes the IUSC's interrupt capabilities and 
how to use them in various system applications. 


The IUSC dedicates four pins to interrupts. It uses 
the /INT output to request an interrupt on the host 
processor. The /INTACK input signals that the proc- 
essor is acknowledging an interrupt, in different ways 
for use with different kinds of host microprocessors. 
(For applications in which interrupt acknowledge 
cycles cannot easily be detected at the IUSC, 
software can simulate such cycles.) 


The Interrupt Enable In (IEl) and Out (IEO) pins allow 
systems including several Zilog-compatible periph- 
erals to use an interrupt acknowledge daisy chain to 
select which of multiple interrupting devices should be 
serviced first. This can eliminate the need for a sepa- 
rate interrupt controller as in other approaches. 
Alternatively, external interrupt control logic can 
process interrupt requests in a round-robin or 
dynamic-priority fashion among one or more |USCs 
and/or other peripheral devices. 


Interrupt Acknowledge Daisy Chains 


Figure 68 shows an interrupt acknowledge daisy 
chain. The highest-priority (or only) daisy-chainable 
device that can request an interrupt has its JEI pin tied 
High. Because of this, it can always request an 
interrupt, and it "has first claim at" providing an inter- 
rupt vector in answer to an interrupt acknowledge 
cycle. Unless the IUSC is the only daisy-chainable 
device that can request an interrupt, the IEO pin of the 
highest-priority device is connected to the IEI pin of 
the next-higher-priority device. This daisy chaining of 
{EO outputs to IEI inputs continues until the lowest- 
priority (or only) daisy-chainable interrupting device, 
which has its IEO pin left unconnected. 


With the IUSC as with all Zilog-compatible devices 
except Z80 family members, the IACK daisy chain 
serves two separate functions. During an interrupt 
acknowledge cycle, the daisy chain acts to select the 
highest-priority requesting device as the one to return 
an interrupt vector. After that, until the resulting inter- 
rupt service routine is over, the daisy chain serves to 
block interrupt requests from devices having a lower 
priority than that of the one currently being serviced, 
while allowing requests from higher-priority devices. 
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Peripheral "A" 1USC 
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Figure 68. An Interrupt Daisy Chain 


This daisy-chain structure allows nesting of interrupt 
service routines. Nesting can greatly improve worst- 
case interrupt response times for critical real-time 
applications as well as 1/O-intensive computing 
systems. Whether or not host software uses nested 
interrupts, the IUSC's interrupt subsystem provides 
the most efficient interrupt handling possible. 


External Interrupt Control Logic 


There are two valid reasons why a system designer 
might choose not to use an interrupt acknowledge 
daisy chain (plus the less valid one of not being 
familiar with them). First, in a system that includes 
many IUSCs all having similar baud rates and serial 
traffic, the strict priority that's inherent in a daisy chain 
might endanger proper interrupt servicing for the 
device(s) at the low-priority end of the chain. In such 
cases, interrupt service requirements may be more 
easily guaranteed by using a central interrupt. 
controller that distributes interrupt acknowledgements 
among the devices on a round-robin (rotating-priority) 
basis. Such schemes target "fairness' rather than 
strict priority in interrupt servicing among the devices. 


A second reason not to use a simple/wired interrupt 
daisy chain would be in a system in which data rates 
vary over a considerable range among several IUSCs, 
and are determined dynamically rather than being 
known as the system is being programmed. (An 
I|USC's interrupt servicing requirements typically vary 
directly with its serial data rate.) In such a system, 
external interrupt logic can distribute interrupt acknow- 
ledge cycles using a dynamic priority determined by 
each |USC's data rate. 


Both rotating-priority and dynamic-priority systems 
can be arranged as shown in Figure 69. The interrupt 
control logic maintains the IEI inputs of the IUSCs 
high most or all of the time, so that they can assert 
their /INT outputs. The logic may simply OR the /INT 
outputs of the various IUSCs to make the interrupt 
request to the processor. Alternatively, in a dynamic- 
priority system with a processor that supports multiple 
levels of interrupts, the control logic may assign 
different |USCs to different processor levels. 


Processor 


Interrupt 
Control 
Logic 


ANT IEIA  /INTACK 


luSC other devices 


Figure 69. External Interrupt Control 


Regardless of how the interrupt control logic derives 
the processor request, when the processor does an 
interrupt acknowledge cycle, the logic must select a 
particular IUSC from among those requesting an 
interrupt, to "receive" the cycle. The control logic can 
implement this choice in one of two ways. First, it can 
negate the IEI inputs of all of the other |USCs, and 
then wait for the specified setup time before present- 
ing the cycle to all of them using the /INTACK signal 
and possibly other bus control signals. Or, it can 
simply present the cycle only to the selected IUSC, 
typically using a single pulse on /INTACK. 


Internal Interrupt Operation 


Internally, the IUSC uses a daisy-chaining scheme 
much like that described earlier. Thus its benefits are 
available, to some extent, even in systems that don't 
include any other Zilog-compatible peripherals. At the 
first level, the IUSC's serial and DMA sections 
("“megacells") have separate interrupt subsystems. 
Their request lines are logically OR'ed to make the 
/ANT output. The IUSC's IEI pin is connected to the 
IE! input of the serial controller; the serial controller's 
IEO output is internally connected to the DMA 
controller's IEl input, and the DMA controller's IEO 
output is routed to the |USC's IEO pin. This 
arrangement means that serial controller interrupts 
have higher priority than DMA controller interrupts. 
The two sections also have fully independent interrupt 
vectors. 


The I|USC carries interrupt daisy-chaining further, to a 
second level of internal resolution. Each section or 
megacell includes several interrupt "types" -- six for 
the serial controller and two for the DMA section. The 
various types in each megacell are arranged a fixed 
priority order in an internal daisy-chain. Each type 
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may request an interrupt due to any of several 
interrupt stimuli or "sources" within it. 


Figure 70 presents a model of the typical internal 
structure of the interrupt subsystem, for a source '"s' 
that is of type "t". Note that the Figure represents a 
model of the IUSC's interrupt logic rather than the 
exact logic; it's included only as an aid to under- 
standing the interrupt subsystem. 


Each individual source has an associated register bit 
that we'll call its Interrupt Arm or IA bit. (Previous 
Zilog documents called this bit an Interrupt Enable or 
IE bit, but also used the same term for another bit that 
applies to the entire type. To distinguish between 
these two kinds of register bits, this description will 
call the one that applies to the individual sources “IA",) 


IA bits are fully under software control. When an IA 
bit is 1, the associated source can cause an interrupt. 


The sources are typically readable as register bits 
themselves, and may be derived from various kinds of 
logic, such as logic that compares the fullness of a 
FIFO with a threshold level at which to interrupt, or 
logic that detects transitions of another register bit. 
Whenever one of the sources for a type and its IA bit 
are both true, an "Interrupt Pending" register bit (IP) 
for the type is set to 1. For the IUSC and other USC 
family members, IP bits are set independently of the 
state of the associated IUS bits, and are cleared to 0 
only by software (or by Reset). 


A close examination of Figure 70 will show that setting 
of IP is delayed if an "armed" source comes true 
during an interrupt acknowledge cycle, but that's not 
particularly important for understanding the |USC's 
interrupt subsystem... 


A second register bit associated with each type is the 
Interrupt Enable or IE bit. This bit is also under full 
software control. When an IE bit is 1, an interrupt can 
be requested when the type's IP bit is 1. Note that an 
IP bit can be set while its associated IE bit is 0; if 
software sets IE when the associated IP bit is set, an 
immediate interrupt can result. 


There is one more register bit for each type, called the 
Interrupt Under Service or IUS bit. The interrupt logic 
sets the IUS bit for a type to 1 during an interrupt 
acknowledge cycle, if the daisy chain shows that it is 
the highest-priority type that's currently requesting an 
interrupt. (This includes types in higher-priority exter- 
nal devices and higher-priority types within the |USC.) 
Aside from a hardware or software Reset, an IUS bit 
can only be reset to 0 by software. This is typically 
done near the end of an interrupt service routine for 
that type. During the execution of the interrupt service 
routine for a given type, the type's IUS bit blocks 
interrupt requests from lower-priority types. 
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Figure 70. A Model of the Interrupt Logic for Source "s" and Type "t" 


The And gate near the top of Figure 70 shows the 
actual conditions for a type to request an interrupt. A 
type's IP and IE bits must both be 1, its IUS bit must 
be 0, and its incoming "IEI" signal must be true. IEl 
true indicates that no higher-priority type (on-chip or 
external) has its IUS bit set. Finally, a Master 
Interrupt Enable (MIE) register bit for the megacell 
must be set to 1. 


Details of the Model 


The IA and IE bits appear near the left side of Figure 
70, as D-type flip-flops that capture the state of an AD 
line when software writes a specific register. The IP 
bit appears as an SR-type latch that's set "by 
hardware" as described above; software can set and 


clear the latch. The signal labelled /I[ACKcy is active 
Low for the duration of an interrupt acknowledge 
sequence. The IUS bit appears as a D-type flip-flop 
that can be set via its clock and D inputs at the end of 
an acknowledge cycle; again, software can set or 
clear IUS. 


The various signals named "SW op x", that set and 
clear IP and |IUS, represent software operations. 
These may reflect the writing of a "1" bit to a certain 
register bit position, or may represent the writing of an 
encoded command to a register. Since software 
always has to clear |US and try to clear IP during an 
interrupt service routine, there are often several ways 
to do so, as shown by the multiple "SW op" signals for 
these functions in the Figure. One thing not shown in 


the Figure is how the typical command "Reset Highest 
IUS" is implemented -- including this function would 
have considerably increased the complexity of the 
logic, which is already complex enough! 


The two downward-pointing gates in Figure 70 form 
the type's "IEO" output. They assert this output only if 
the type's incoming IEI is High and its IUS bit is 0. 
There is a register bit "Disable Lower Chain" (DLC) in 
each megacell; if/when DLC is 1 the megacell's IEO is 
forced false/low. The downward-pointing OR gate 
reflects the functional shift of the daisy-chain during 
interrupt-acknowledge cycles. Its output is High 
except during IACK cycles, at which time it allows IEO 
to be asserted High only if this type is not requesting 
an interrupt. 


Finally, the signal labelled "Drive Vector" controls 
when the megacell places an interrupt vector on the 
data bus during an interrupt acknowledge cycle. 
There is a register bit No Vector (NV) in each 
megacell; NV=1 prevents driving a vector. The bus 
interface logic derives the signal "I|ACK Read" from 
R//W and /DS, /RD, or /INTACK, depending in part on 
a field in the Bus Configuration Register (BCR) that 
specifies how /INTACK works. In most cases IACK 
Read is true during the latter part of the time that 
/|[ACKcy is true. The megacell provides a vector on 
AD7-0 while IACK Read is true, if NV is 0 and any of 
the types in the megacell is the highest priority 
interrupting type. 


To keep its complexity reasonable, Figure 70 doesn't 
include the mechanism by which the content of a 
returned interrupt vector can reflect the identity of the 
highest-priority interrupting type within the megacell. 


Software Requirements 


While there's considerable variability and flexibility in 
the IUSC's interrupt subsystem, there are some 
common requirements in what an interrupt service 
routine must do to keep the hardware operating 
correctly: 


1. Ifthe ISR wants to allow nested interrupts, it can 
re-enable processor interrupts near its start. The 
IUSC won't request another interrupt of the same 
type (or any lower-priority type) until software 
clears the type's IUS bit. 


The service routine must figure out which type of 
interrupt it's servicing. This is automatic if the 
software enables the "Vector Includes Status’ 
(VIS) options of the serial and DMA controller 
sections. 

Next the service routine must choose which 
source(s) within the type it wants to deal with. For 
each such source that's both active and armed, it 
must clear the source signal (whatever that takes) 
or, less typically, clear the associated IA bit. 
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4. After dealing with as many sources for the type as 
it can, it must clear both the IP and IUS bits for 
the type. This may involve writing one or two 
specific register bit(s) or writing one or two 
encoded command(s) to a register. The IP bit 
{remains set | is set again immediately} if the 
service routine left any sources for the type both 
active and armed. 


Typically the service routine then returns to the 
interrupted process or program. 


The |USC's serial controller and DMA section provide 
register bits and/or commands to set the IP and/or 
|US bits as well as clear them. Software can set IP to 
force an initial interrupt from a previously-inactive 
type. The ability to set IUS may be needed as part of 
simulating an interrupt acknowledge cycle. 


Interrupt Options in the BCR 


Two fields in the Bus Configuration Register (BCR) 
affects the interrupt subsystem. The following is also 
presented in Chapter 2, Bus Interfacing. 


The l[AckMode field (BCR5-4) tells the IUSC how the 
host processor drives the /INTACK pin. OO makes the 
|\USC capture the state of /INTACK at the start of each 
bus cycle. It does this at rising edges on /AS on a bus 
with multiplexed addresses and data, or at falling 
edges on /DS or /RD on a non-multiplexed bus. 


This field should be written as 01 if /INTACK carries a 
single low-active pulse during an interrupt acknowl- 
edge cycle. 


The 10 value in IACKMODE is reserved and should 
not be programmed. 


IACKMODE should be written as 11 if /INTACK 
carries a double pulse during an interrupt acknow- 
ledge sequence. This mode is compatible with 
several Intel microprocessors. 


lf the /IRQTP bit (BCR1) is 0, the IUSC drives its /INT 
pin in a totem-pole fashion (both high and low). If 
/IRQTP is 1, the IUSC drives /INT in an open-drain 
fashion (low only) so that the request can be wire- 
ORed, in which case an external pull-up resistor 
should be provided. 


Interrupt Acknowledge Cycles 


The IUSC doesn't require Interrupt Acknowledge 
cycles. The system designer can simply pull up the 
/IINTACK pin, and software can read the Interrupt 
Pending (IP) bits in the Daisy Chain Control Register 
(DCCR) and the Set DMA Interrupt Register (SDIR), 
which are described in later sections. 


Even if the host processor does Interrupt Acknow- 
ledge cycles, the 1USC doesn't have to provide a 
vector. If IEI is high and the NV bit in the Interrupt 


Control Register (ICR) or DMA Interrupt Control 
Register (DICR) is 1, the IUSC sets the IUS bit of the 
highest priority interrupt then pending, but it does not 
return an interrupt vector. 


But, since most microprocessors in use today perform 
interrupt acknowledge cycles to obtain an 8-bit inter- 
rupt vector, the rest of this section will assume 
vectored interrupts. 


Figure 71 shows the kind of interrupt acknowledge 
cycle that the IUSC expects when the |AckMode field 
(BCR5-4) is 00, on a bus with multiplexed addresses 
and data. (Actually there are two subcases of this 
kind of cycle, depending on whether the host 
processor uses /DS or /RD signalling. Since the timing 
is the same for either strobe, Figure 71 simply shows 
a trace labelled "/DS or /RD".) 


If the IUSC samples /INTACK low at the rising edge of 
/AS, it "freezes" its internal interrupt state; if it is 
requesting an interrupt it forces its IEO output low 


regardless of the state of IEI, and starts resolving its 
internal interrupt priorities. If the [El and IEO pins are 
part of an interrupt acknowledge daisy chain with 
other interrupting devices, this resolution occurs in 
concert with the interrupt logic in the other devices. 


The IEl pin must be valid for a specified setup time 
before /DS or /RD goes low. The host CPU's strobe 
must be delayed if needed to guarantee this. If IEI is 
high and the IUSC is requesting an interrupt, it 
responds to /DS or /RD by setting the IUS bit of its 
highest requesting type of interrupt, driving a vector 
onto the AD7-0 pins, and driving /WAIT//RDY 
appropriately to signal when the vector is valid. If IE 
is low at the leading/falling edge of /DS or /RD, and/or 
if the IUSC is not requesting an interrupt, it doesn't 
respond to the cycle. 
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Figure 71. An Interrupt Acknowledge Cycle with IACKMODE=00 on a Multiplexed Bus 





Figure 72 shows the kind of interrupt acknowledge 
cycle that the IUSC expects when the IAckMode field 
(BCR5-4) is 00, on a bus with separate address and 
data lines. (As before there are two subcases of this 
kind of cycle, depending on whether the host 
processor uses /DS or /RD signalling. Since the 
timing is identical for either strobe, Figure 72 simply 
shows a trace labelled '"/DS or /RD".) 


Here the IUSC freezes its internal interrupt state in 
response to a falling edge on /INTACK; again, if it is 
requesting an interrupt it forces its IEO output low 
regardless of the state of IEI, and starts resolving its 
internal interrupt priorities. 





AD15-0 


| 


In this mode /INTACK must stay low until after /DS or 
/RD goes low, and IEI must be valid for a specified 
setup time before /DS or /RD goes low. (The falling 
edge of /DS or /RD may have to be delayed to 
guarantee this.) If IEIl is high and the !USC is 
requesting an interrupt, it responds to /DS or /RD by 
setting the IUS bit of its highest priority requesting 
type of interrupt, driving a vector onto the AD7-0 pins, 
and driving /WAIT//RDY appropriately to signal when 
the vector is valid. If IEl is low at the leading/falling 
edge on /DS or /RD, and/or if the IUSC is not 
requesting an interrupt, it doesn't respond to the cycle. 
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Figure 72. An Interrupt Acknowledge Cycle with IACKMODE=00 on a Non-Multiplexed Bus 
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Figure 73 shows the kind of interrupt acknowledge 
cycle that the IUSC expects when the lAckMode field 
is 01. Here a single pulse on /INTACK substitutes for 
the pulse on /DS or /RD in the previous cases; the 
latter two signals must remain high throughout the 
cycle. For this case, operation on a non-multiplexed 
bus is identical with that on a multiplexed bus once 
the /AS strobe is over. The only distinction is that a 
multiplexed bus must meet minimum times between 
the pulse on /INTACK and the preceding and following 
pulses on /AS. These minima are similar to those 
required for register read and write cycles. 


In this mode, an interrupt acknowledge daisy chain on 
IEI/IEO cannot be used to select whether the IUSC or 
another device should respond to each interrupt 
acknowledge cycle. Instead, external logic like that 


AD15-0 


shown in Figure 69 must decide which requesting 
device is to respond to an interrupt acknowledge 
cycle, if such a cycle occurs when more than one is 
requesting an interrupt. The external logic would 
typically consider the state of the individual requesting 
devices’ interrupt request lines in making this decision. 
(The lines cannot be OR-tied in this case.) 


In this "single-pulse" mode, the IEI pin must set up 
and hold around the leading/falling edge on /INTACK. 
If IEl is high and the IUSC is requesting an interrupt at 
that point, it responds to /INTACK by driving a vector 
onto the AD7-0 pins and driving /WAIT//RDY 
appropriately to signal when the vector is valid. If IE! 
is low at the leading/falling edge of /INTACK, and/or if 
the IUSC is not requesting an interrupt at that point, it 
doesn't respond to the cycle. 
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Figure 73. An Interrupt Acknowledge Cycle with IACKMODE=01 








Figure 74 shows the kind of interrupt acknowledge 
cycle that the |USC expects when the lAckMode field 
is 11. Here, two consecutive low pulses on /INTACK 
constitute the complete interrupt acknowledge cycle, 
and /DS and /RD should both stay high throughout the 
cycle. This mode is compatible with several 
microprocessors made by Intel Corp. and other 
companies. As in the preceding case, operation is 
similar whether the bus is multiplexed or non- 
multiplexed. The multiplexed bus must meet 
minimum times between the pulses on /AS and the 
pulses on /INTACK. These minima are similar to 
those between /AS and /DS or /RD in register read 
cycles, 


In "double pulse mode" the IUSC keeps an internal 
state bit that distinguishes the two /INTACK pulses in 
each pair. The IUSC freezes its internal interrupt 


state in response to the first falling edge on /INTACK. 
If it is requesting an interrupt it forces its IEO output 
low regardless of the state of IEI, and starts resolving 
its internal interrupt priorities, but the IUSC does not 
otherwise respond to the first cycle. 


In this mode the IEI pin must be valid for a specified 
setup time before /INTACK goes low for the second . 
pulse. If IEI is high at this point and the IUSC is 
requesting an interrupt, it responds to the second 
/INTACK pulse by setting the JUS bit of its highest- 
priority requesting type of interrupt, driving a vector 
onto the AD7-0 pins, and driving /WAIT//RDY 
appropriately to signal when the vector is valid. If |EI 
is low at the leading edge of /INTACK, and/or if the 
IUSC is not requesting an interrupt, it doesn't respond 
to the cycle. 
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Figure 74. An Interrupt Acknowledge Cycle with IACKMODE=11 


Interrupt Acknowledge vs. Read Cycles 


Interrupt Acknowledge cycles are similar to the cycles 
that occur when the host processor reads an IUSC 
register, which are discussed in Chapter 2. However, 
the user should note the following ways in which 
interrupt acknowledge cycles differ from read cycles: 


* With [AckMode=00 on a multiplexed bus, 
/INTACK acts like an address line. When an 
IUSC samples /INTACK low at a rising edge on 
/AS, it ignores the address on the AD lines. 


* On anon-multiplexed bus with [AckMode=00, 
each leading edge of /RD or /DS captures the 
state of /INTACK. 


* With |[AckMode=00 and /DS signalling, the state of 
R//W doesn't matter for a cycle in which the |IUSC 
samples /INTACK low. (In other cycles R//W 
differentiates Read cycles from Writes.) 


* When the /WAIT//RDY pin carries the Wait 
function, the IUSC asserts the pin during interrupt 
acknowledge cycles, but never does so during 
register Read or Write cycles. 

* When /WAIT//RDY carries the Acknowledge 
function, the IUSC asserts it later in Interrupt 
Acknowledge cycles than in Reads. However, the 
relationship between the falling edge of (WAIT 
//RDY and the validity of data on the AD lines is 
similar in both kinds of cycles. 


Serial Controller Interrupt Types 


The serial controller section of the IUSC includes six 
types of interrupts, arranged on the internal interrupt 
daisy chain in the following priority order: 


Receive Status (highest priority) 
Receive Data 

Transmit Status 

Transmit Data 

I/O Pin 

Miscellaneous (lowest priority) 


ot er 


Each of these types has one each IE, IP, and IUS bit, 
as described in an earlier section of this chapter. 


Receive Status Interrupt Sources and IA Bits 


Any of six interrupt sources can set the Receive 
Status IP bit. Software can read the status of each 
source in the LSByte of the Receive Command / 
Status Register (RCSR), which is shown in Figure 75. 
The following descriptions of the RCSR status bits are 
similar to those in the Detailed Status in the RCSR 
section of Chapter 4: 


ExitedHunt The RS IP bit can be set when this 
bit (RCSR7) goes from 0 to 1 
because the receiver has detected 
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idleRcved 


Break/Abort 


RxBound 


Abort/PE 


RxOver 


a Sync or Flag sequence in a 
synchronous mode. 

The RS IP bit can be set when this 
bit (RCSR6) goes from 0 to 1 
because the receiver has seen 15 
or 16 consecutive one bits. In 
asynchronous modes with 16, 32, 
or 64X clocking, the receiver sets 
RCSR6 after one bit time or less; so 
this source's IA bit shouldn't be set 
in any async mode. 

The RS IP bit can be set when this 
bit (RCSR5) goes from 0 to 1 
because the Receiver has detected 
a Break condition in an asynch- 
ronous mode or an Abort condition 
in aan HDLC/SDLC mode. 

lf the IA bit for this source is 1, the 
interrupt logic sets the RS IP bit 
when software or the Receive DMA 
channel reads a character from the 
RxFIFO that's marked with 
RxBound status. Such marking 
reflects an address character in 
Nine-Bit mode, a word boundary in 
1553B mode, negation of /DCD 
during the character in external 
sync mode, the last character of a 
frame in HDLC/SDLC and 802.3 
modes, or one of five block term- 
inating characters in Transparent 
Bisync mode. 

lf the IA bit for this source is 1, the 
interrupt logic sets the RS IP bit 
when software or the Receive DMA 
channel reads a character from the 
RxFIFO that failed parity checking, 
or, in HDLC/SDLC mode with the 
QAbort bit (RMR8) set, a character 
that was followed by an Abort 
sequence. 

lf the IA bit for this source is 1, the 
interrupt logic sets the RS IP bit 
when software or the Receive DMA 
channel reads a character from the 
RxFIFO that's marked with Overrun 
status. The character so marked is 
the first one that arrived while the 
FIFO was full; the character before 
this one is lost, and an indeter- 
minate number after it may have 
been lost as well. 
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Figure 76. The Receive Interrupt Control Register (RICR) 





As described in Chapter 4, once an Interrupt-Armed 
RCSR bit has been set, it must be "unlatched" by 
writing a 1 to that bit position in RCSR. For Exited 
Hunt, Abort (in HDLC mode), RxBound, Abort/PE, and 
RxOver, this action. also clears the RCSR bit. The 
IdleRcved and Break/Abort (in async modes) bits in 
RCSR don't become 0 until software has unlatched 
the bit and the line condition has ended. 


Each of these six sources has a separate Interrupt 
Arm (IA) bit in the LSByte of the Receive Interrupt 
Control Register (RICR). Figure 76 shows the RICR. 
lf an IA bit is 1, the interrupt logic sets the Receive 
Status IP bit as described above. If an IA bit is 0, the 
corresponding bit in RCSR has no effect on the IP bit 
and thus will not cause interrupts. The setting of the 
IA bits for the ExitedHunt, IdleRcved, and Break/Abort 
conditions has no effect on the bits in RCSR, while the 
IA bits for the RxBound, Abort/PE, and Overrun 
conditions affect how the corresponding RCSR bits 
operate, as described in Chapter 4. 


Receive Data Interrupts 


This interrupt type has only one source, so there's no 
IA bit for it. The interrupt logic sets the RD IP bit 
when a character is received and the number of pre- 
viously-received characters in the RxFIFO is equal to 
the number programmed as the "Receive Data Inter- 
rupt Request Level". That is, the IP bit is set when a 
character is received, that makes the number of char- 
acters in the RxFIFO exceed the programmed value. 


The RD IP bit is also set if the number of characters is 
less than the programmed threshold level, and the 
receiver places a character marked with RxBound 
status in the RxFIFO. 


lf received data is handled by either software polling 
or the Receive DMA channel, disable the Receive 
Data interrupt by leaving its IE bit O. (A later section 
discusses IE bits.) 


To program the Receive Data Interrupt Request Level, 
first write the "Select RICRHi=/INT Level" command to 
the RCmd field of the Receive Command/Status 
Register (RCSR15-12). Then write the number of 


received characters at which the IUSC should start 
requesting a Receive Data interrupt, minus one, to the 
MSByte of the Receive Interrupt Contro! Register 
(RICR). For example, if the IUSC should request a 
Receive Data interrupt when its 32-byte RxFIFO 
becomes 3/4 full, write hex 60 to RCSR15-8, then 
write decimal 23 (hex 17) to RICR15-8. 


Figure 77 shows a sample service routine for Receive 
Data interrupts. While it's not particularly fancy or 
efficient, it does illustrate several important points: 


1. It reads the FIFO fill level to determine how many 
characters to read. The fact, that reception of an 
RxBound character (i.e., the last character of a 
frame, message, or ACV/1553B word) can set the 
Receive Data IP bit, means that a Receive Data 
interrupt service routine can't blindly read the 
number of characters implied by the Interrupt 
Request Level. 


2. It explicitly clears the Receive Data IP and IUS 
bits by writing to the Daisy Chain Control Register 
(DCCR) as described in a later section. Neither 
bit is affected by reading data from the RxFIFO. 


3. It re-reads the FIFO fill level after clearing the IP 
bit, and processes any characters that have been 
received while it was processing earlier charac- 
ters. This procedure guards against losing an 
interrupt associated with a late-arriving End of 
Frame (RxBound) character. 

4. \treads the status from RCSR "before" reading 
each character, and reads RCSR an extra time 
after reading out an End of Frame (RxBound) 
character, to clear the latching of the status that _ 
occurs when an RxBound character is read out. 


(This is not the only way to handle RxBound 
checking. Another way is to enable a Receive 
Status interrupt when the Receive Data interrupt 
service routine reads an RxBound character out of 
the RxFIFO, and not check RxBound status in this 
routine at all. Software that uses this method 
must ensure that an Receive Status interrupt can 
interrupt the Receive Data ISR in a "nested" 
fashion.) 
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Start: Interrupt with 
Vector = "Rx Data" 


IF NECESSARY, 
write 0101 to 
RCmd (RCSR15-12) 


Read FIFO count 
CT:=RICR15-8 



























Clear the RD IP bit 
(write 9016 
to DCCR7-0) 







Read FIFO count 
CT:=RICR15-8 


Yes 


Read Status 
from RCSR. 
Handle bits other than 
RxBound as required. 







Read & store last 
byte/word from RDR. 
Decrement CT by 
1 or 2 accordingly 








Clear the RD IUS bit 
(write 9016 
to DCCR15-8) 


Return from 
Interrupt 














Read & store byte 
or word from RDR. 
Decrement CT by 
1 of 2 accordingly 







Read RCSR15-8 
or RCSR15-0, to 
clear latched status 








Perform End of 
Frame processing 
(switch buffers etc.) 


Figure 77. A Sample Service Routine for Receive Data Interrupts 


117 





"TTSA data" If last TCSR15-12 command 4-7 was 4 
“TXFIFO fill level" if last TCSR15-12 command 4-7 was 5 
"Tx Int Req level" If last TCSR15-12 command 4-7 was 6 
level" if last TCSR15-12 command 4-7 was 7 


"Tx DMA Reg 


Pre idle Abort 
15 14 13 12 11 10 9 8 7 6 5 


CRC Tx Tx 
Sent Under | Empty 
3 2 1 0 


4 
Figure 78. The Transmit Command/Status Register (TCSR) 
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IA 
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Sent 
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Figure 79. The Transmit Interrupt Control Register (TICR) 


Transmit Status Interrupt Sources and IA Bits 


The interrupt logic can set the Transmit Status IP bit 
in response to any of six interrupt sources. Software 
can read the status of each source in the LSByte of 
the Transmit Command/Status Register (TCSR), 
which is shown in Figure 78. The following descrip- 
tions of the TCSR bits are similar to those in the 
Detailed Status in the TCSR section of Chapter 4: 


PreSent The interrupt logic can set the TS IP 
bit when this bit (TCSR7) goes from 
a0 to a1, because the transmitter 
has finished sending the "Preamble" 
selected in the Channel Control 
Register (CCR11-8) ina 
synchronous mode. 

The interrupt logic can set the TS IP 
bit when this bit (TCSR6) goes from 
a0 to a1, because the transmitter 
has sent the idle line state selected 
by the Txldle field (TCSR10-8). If 
Tx!dle and TxMode specify the 
condition as Flags or Syncs, this bit 
can be set for each one sent. 
Otherwise, for bit-oriented Idle 
conditions, it's set only after the first 
bit is sent. 

The interrupt logic can set the TS IP 
bit in HDLC/SDLC mode, when this 
bit (TCSRS5) goes from 0 to 1 
because the transmitter has sent an 
Abort character. 

The interrupt logic can set the TS IP 
bit in a synchronous mode, when 
this bit (TCSR4) goes from 0 to 1 
because the transmitter has sent 
the closing Flag or Sync character 
at the end of a message or frame. 
The interrupt logic can set the TS IP 
bit in a sync mode, when this bit 
(TCSR8) goes from 0 to 1 because 
the transmitter has sent the CRC 
sequence just before the end ofa 
message or frame. 


IdleSent 


AbortSent 


EOF/EOM Sent 


CRCSent 
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TxUnder The interrupt logic can set the TS IP 
bit when this bit (TCSR1) goes from 
0 to 1, because the transmitter 
needed a character from the 


TXxFIFO but it was empty. 


All six of these sources operate differently from the 
general model described earlier, in that the interrupt 
logic sets the IP bit only when a TCSR bit goes from 0 
to 1 and its associated IA bit is 1. Once one of these 
TCSR bits is 1, it must be cleared to 0 by writing a 1 
to that bit position in TCSR. 


Each of these six sources has a separate Interrupt 
Arm (IA) bit in the LSByte of the Transmit Interrupt 
Control Register (TICR). Figure 79 shows the TICR. 
lf an IA bit is 1, the interrupt logic sets the Transmit 
Status IP bit when the corresponding bit in the 
Transmit Command / Status Register (TCSR) goes 
from 0 to 1. If an JA bit is 0, the corresponding TCSR 
bit has no effect on the IP bit and thus will not cause 
interrupts. The setting of the IA bits in TICR has no 
direct effect on the TCSR bits. 


Transmit Data Interrupts 


This interrupt type has only one source, so there's no 
need for an IA bit for it. The interrupt logic sets the 
Transmit Data IP bit whenever the number of empty 
character positions in the TxFIFO is greater than 
the number programmed as the "Transmit Data 
Interrupt Request Level". If transmitted data is to be 
handled by the Transmit DMA channel, disable this 
interrupt by leaving its IE bit 0. (A later section 
discusses IE bits.) 


To program the Transmit Data Interrupt Request 
Level, first write the "Select TICRHi=/INT Level’ 
command (value 0110) to the TCmd field of the 
Transmit Command / Status Register (TCSR15-12). 
Then write the number of empty character positions at 
which the IUSC should start requesting a Transmit 
Data interrupt, minus one, to the MSByte of the 
Transmit Interrupt Control Register (TICR). For 
example, if the IUSC should request a Transmit Data 
interrupt when its 32-byte TxFIFO has only four 
characters left in it, write hex 60 to TCSR15-8, then 
write decimal 27 (hex 1B) to RICR15-8. 





RxCDn TxCDn | TxCUp | RxRDn | RxRUp| TxRDn | TxRUp |DCDDn|DCDUp| CTSDn| CTSUp is ita BRG1 | BRGO 
IA IA IA IA IA IA IA IA iA IA IA cee be IA IA 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 





Figure 80. The Status Interrupt Control Register (SICR) 





RCC | OPLL | preg: | BRGO 

RxCL/U| /RxC |TxCL/U} /TxC |RxRL/U| /RxR |TXRL/U! /TxR |DCDL/U] /DCD |CTSL/U; /CTS | Under | DSync L/U L/U 
L/U L/U 

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 





Figure 81. The Miscellaneous Interrupt Status Register (MISR) 


Note that a Purge Tx FIFO (or Purge Rx and Tx FIFO) 
command will typically make the IUSC immediately 
set its Transmit Data IP bit. This will, in turn, make it 
start requesting an interrupt on its /INT pin if: 

* it hadn't been doing so, 

* the IEI pin is high, 

*its TD IE and MIE bits are 1, and 

*its TD IUS and all higher-priority |US bits are 0. 


As with all [USC interrupts, a Transmit Data interrupt 
service routine must explicitly clear the Transmit Data 
IP and IUS bits by writing to the Daisy Chain Control 
Register (DCCR) as described later; the bits aren't 
cleared by simply writing data into the TxFIFO. 


I/O Pin Interrupt Sources and IA Bits 


The interrupt logic can set the I/O Pin IP bit in 
response to rising and/or falling edges on any of six 
pins, namely /RxC, /TxC, /RxREQ, /TxREQ, /DCD, 
and /CTS. The following description is similar to that 
in the Edge Detection and Interrupts section of 
Chapter 3. 


software can program the |IUSC to detect rising 
and/or falling edges on the /CTS, /DCD, /TxC, /RxC, 
/TxREQ, and /RxREQ pins, and to interrupt when 
such events occur. Figure 80 shows that the Status 
Interrupt Control Register (SICR) includes separate 
Interrupt Arm (IA) bits for rising and falling edges on 
each of these pins. A 1 in one of these bits makes the 
IUSC detect that kind of edge, while a 0 makes it 
ignore such edges. This edge detection and interrupt 
mechanism operates without regard for whether the 
various pins are programmed as inputs or outputs in 
the 1/O Control Register (IOCR). 


When the IUSC detects an edge that's enabled in the 
SICR, it records the event in an internal latch that's 
not directly accessible in the IUSC's register map. 
Instead, as shown in Figure 81, the Miscellaneous 
Interrupt Status Register (MISR) includes two bits for 
each of these six pins, one called a "Latched/Unlatch" 
or L/U bit, and the other being a "data bit" that has the 
same name as the pin itself. 


A hardware or software Reset sequence clears all the 
L/U bits to zero. While the L/U bit for a pin is 0, the 


119 


associated data bit reports and tracks the state of the 
pin in a "transparent" fashion, with a 1 indicating a low 
and a O indicating a high. 


Whenever a pin's L/U bit is 0 and its internal edge- 
detecting latch is set, the IUSC sets the L/U bit to 1, 
clears the detection latch, and sets the JOP IP bit. 
IOP IP can be read and cleared (and if necessary set) 
in the Daisy Chain Control Register (DCCR1). 


While an L/U bit is 1, the state of the associated data 
bit is frozen (latched). These two bits remain in this 
state, regardless of further transitions on the pin, until 
software writes a 1 to the L/U bit. This clears the L/U 
bit to O and "opens" the data bit to once again report 
and track the state of the pin, at least for an "instant", 
lf one or more enabled transitions occurred while the 
L/U bit was set, then L/U is set again right after 
software writes the 1 to it. 


Writing a O to an L/U bit has no effect; it doesn't 
matter what value software writes to the status bits. 


Miscellaneous Interrupt Sources and IA Bits 


The interrupt logic can set the Miscellaneous IP bit in 
response to any of four interrupt sources. Software 
can read the status of these sources in the LSByte of 
the Miscellaneous Interrupt Status Register (MISR), 
which is shown in Figure 81. The following descrip- 
tions repeat some information that was presented in 
Chapters 3 and 4: 
RCCUnder If the RCCUnder IA bit is 1, the 
IUSC sets this bit (MISR3) and 
the Misc IP bit if the receiver has 
decremented the Receive 
Character Counter (RCC) to zero 
and then it receives another 
character (in the same frame / 
message). 

If the DPLLUnder IA bit is 1, the 
IUSC sets this bit (MISR2) and 
the Misc IP bit if software set up 
the Digital Phase Locked Loop 
circuit for Bipnhase encoding and 
the DPLL detects two consecutive 
missing clocks, indicating a loss 
of synchronization. 


DPLLDSync 


If the BRG1 IA bit is 1, the IUSC 
sets this bit (MISR1) and the Misc 
IP bit when Baud Rate Generator 
1 counts down to zero. 

If the BRGO IA bit is 1, the IUSC 
sets this bit (MISRO) and the Misc 
IP bit when Baud Rate Generator 
0 counts down to zero. 


BRG1 


BRGO 


Once any of these bits is 1, software must write a 1 to 
that bit position to "unlatch" it. Writing a 1 to any of 
MISR3-0 clears the "read-side" bit unless the setting 
event recurred while the bit was latched, in which 
case the bit is set again immediately. 


Each of these four sources has a separate Interrupt 
Arm (IA) bit in the LSByte of the Status Interrupt 
Control Register (SICR). Figure 80 shows the SICR. 
lf an IA bit is 1, the interrupt logic sets the corres- 
ponding bit in MISR, and the Miscellaneous IP bit, 
when the indicated condition occurs. If an IA bit is 0, 
the corresponding MISR bit is not set and thus the 
associated condition can't cause interrupts. Clearing 
an IA bit does not clear the corresponding bit in MISR. 


Serial IP and IUSC Bits 


Software can read, set, and clear the Interrupt 
Pending (IP) and Interrupt Under Service (IUS) bits, 
for all six interrupt types in the serial controller, via the 
Daisy-Chain Control Register (DCCR). Figure 82 
shows the DCCR. The MSByte deals only with the 
IUS bits, while the LSByte deals with the IP bits but 
can be used to clear the IP and IUS bits in one step. 


Software can read the six IUS bits from DCCR13-8 
and the six IP bits from DCCR5-0. The two MSBits of 
each byte always read as 00. When software writes 
the DCCR, the two MSBits of each byte can represent 
a command that is applied to the type(s) selected by 
ones written in the six LSBits of that byte. DCCR15- 


14 are an IUS Op field that the IUSC interprets as 
follows: 
IUS Op Operation 
Ox No operation 
10 Clear the IUS bit(s) of the 
type(s) selected in DCCR13-8 
11 Set the IUS bit(s) of the 


type(s) selected in DCCR13-8 


DCCR7-6 are an IP Op field that the IUSC interprets 
as follows: 
IP Op Operation 

00 No operation 

01 Clear both the IP and IUS 
bit(s) of the type(s) selected 
in DCCR5-0 
Clear the IP bit(s) of the 
type(s) selected in DCCR5-0 


10 
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11 Set the IP bit(s) of the 


type(s) selected in DCCR5-0 


If software writes both bytes of the DCCR simul- 
taneously on a 16-bit bus, the IUS command is 'set', 
the IP command is "clear both", and a particular type 
is selected by ones in both the MSByte and LSByte, 
the IUSC clears the IUS bit for that type. On the other 
hand, if the IUS command says "set" for a type and 
the LSbyte says "clear both" but that type's bit in 
DDCR8-0 is 0, the IUSC sets that type's IUS bit. 


In addition, one of the encoded commands that can 
be written to the Channel Command/Address Register 
(CCAR) allows for a general exit from a serial 
controller interrupt service routine, regardless of which 
type initiated the routine. If software writes the Reset 
Highest Serial |US command (00010) to the RTCmd 
field (CCAR15-11), it clears the highest-priority I|US bit 
that's set in the serial controller. Unfortunately, the 
command doesn't also clear the corresponding IP bit, 
so that an interrupt service routine has to do this 
explicitly for the particular type that it's servicing. 


Serial Interrupt Enable Bits 


Software can read, set, and clear the Interrupt 
Enable (IE) bits for all six interrupt types in the serial 
controller, in the LSByte of its Interrupt Control 
Register (ICR). Figure 83 shows the ICR. Software 
can read all six IE bits from ICR5-0; ICR7-6 always 
read as 00. When software writes the LSByte of the 
ICR, the IE Op field (ICR7-6) comprises a command 
that the |USC applies to any and all IE bits selected by 
ones written to ICR5-0. The IUSC interprets IE Op as 
follows: 


IE Op OQperation 
Ox No operation 
10 Clear the IE bit(s) of the 
type(s) selected in ICR5-0 
11 Set the IE bit(s) of the 


type(s) selected in ICR5-0 


Serial Controller Interrupt Options 


Figure 83 shows that the MSByte of the Interrupt 
Control Register (ICR) contains control bits that apply 
to all interrupts from the serial controller. These bits 
are fully under software control and can be read or 
written at any time. 


The Master Interrupt Enable (MIE; ICR15) must be 
set to 1 to allow any of the types in the serial 
controller to request an interrupt. 


Whenever the Disable Lower Chain bit (DLC; ICR14) 
is 1, the serial controller forces its [EO output low, so 
that neither the IUSC's DMA channels, nor external 
devices further down the daisy chain, can request int- 
errupts nor respond to interrupt acknowledge cycles. 


lUS Op TS TD IP Op TS TD 
(Wo) lus | tus (Wo) IP IP 
15 14 13 12 


Figure a tae mage chain ial ne (weer) 


IE Op TS TD Misc 
vis 


15 14 13 12 11 
Figure so the intern eile ee 408) 


interrupt Vector 7-4 (RO) TypeCode (RO) 5) Interrupt Vector (RW) 


15 14 13 12 11 10 AS) 8 7 6 5 4 3 2 1 0 
Figure 84. The Interrupt Vector Register (IVR) 


If the No Vector bit (NV; ICR13) is 1, the IUSC acknowledge cycle in which the highest priority 
neither provides a vector nor drives the /WAIT//RDY _ requesting type is in the serial controller. 

pin during an interrupt acknowledge cycle in which the 
highest-priority requesting type is in the serial 
controller. However, in such a case the IUSC still sets 
the IUS bit of the highest-priority requesting type. 


Figure 84 shows the IVR. The basic vector can be 
written and read in its LSByte; software can read a 
modified version of the vector in its MSByte. (Writing 
the MSByte has no effect.) Bits 15-12 and 8 are the 
The Vector Includes Status field (VIS; ICR12-9) image of those in the corresponding bits of the 
controls whether the vector, that the IUSC returns LSByte, while the TypeCode field (IVR11-9) gives the 
during an interrupt acknowledge cycle in which the identity of the highest priority interrupt type that has its 


highest-priority requesting type is in the serial con- IP bit set (the state of its |IUS bit doesn't matter). 
troller, identifies the type or not. Such vector modifi- TypeCode Meaning 
cation can be enabled for all types in the serial con- 000 No serial interrupt pending 
troller, or only for those above a selected priority level: (61: MiecelTaneous 

VIS Which types appear in vectors O10. “2/0 pin 

Oxxx No types Oll Transmit Data 

100x All types 100 Transmit Status 

1010 IOP and above (not Misc) 101 Receive Data 

1011 Transmit Data and above 110 Receive Status 

1100 Transmit Status and above 111 (will not be read) 


1101 Receive Data & Status 
1110 Receive Status only 
1111 No types 


The state of the VIS field (ICR12-9) has no effect on 
reading the IVR. VIS simply controls how the serial 
controller decides whether to return IVR15-8 or IVR7- 
If the contents of VIS allow the highest-priority type, 0 as the interrupt vector when it responds to an 
that's requesting at the time of an Interrupt interrupt acknowledge cycle for which the highest 
Acknowledge cycle, to modify the interrupt vector, priority requesting type is in the serial controller. 

then bits 4-1 of the returned vector identify that type 

as described in the next section. If not, the IUSC DMA Controller Interrupt Types 

returns the 8-bit vector exactly as the host software There are only two interrupt types in the DMA 


programmed it. Controller section of the IUSC, one each for the trans- 
: mit and receive channels. Receive channel interrupts 
Serial Interrupt Vectors have higher priority than Transmit channel interrupts. 
The vectors returned by the IUSC for interrupts from = Each DMA channel has one each IE, IP, and IUS bit, 
the serial controller section are independent of those = as described in an earlier section of this chapter. The 
from the DMA section. Software can read and write interrupt capabilities of the two channels are identical 
serial interrupt vector information in the Interrupt and, except as noted, the information in the rest of 
Vector Register (IVR). This register is also the basis this section applies equally to both. 
of the vector that the IUSC returns during an interrupt 
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DMA Interrupt Sources and IA Bits 


Software can set each DMA channel's IP bit in 

response to any of 4 possible interrupt sources, which 

are readable as the four LSBits of each DMA Mode 

Register (TDMRS3-0 and RDMR@8-0): 

EOA/EOL A DMA channel sets this bit (KDMR3) in 
Array and Linked List modes, when it goes 
inactive because it fetches a zero Byte 
Count from an array or list entry, indicating 
the end of the array or list. 


A DMA channel sets this bit (KDMR2) in 
any mode, when it decrements the Byte 
Count for the current buffer (TBCR or 
RBCR) to zero. It also sets this bit if 
software has enabled the Early 
Termination feature, when the serial 
controller signals for buffer termination. In 
Single Buffer mode the channel goes 
inactive at this time. The channel also 
goes inactive at this time in Pipelined 
mode, if the software hasn't provided a 
new buffer address and byte count and set 
the CONT bit (xDMR7). 

A channel sets this bit (XDMR1) in any 
mode, if external hardware drives the 
/ABORT pin low during a bus cycle by the 
channel. The channel goes inactive when 
this occurs, regardless of the mode. 

A channel sets this bit (XDMR0O) in any 
mode, if host software writes an Abort This 
Channel or Abort All Channels command 
to the MSByte of the DMA Command / 
Address Register (DCAR). The channel 
goes inactive when this occurs, regardless 
of the mode. 

As noted in Chapter 4, the channel clears all four of 
these bits whenever software reads them in the LS 
byte of its DMA Channel Mode Register (xDMR7-0). 


Each of these four sources has a separate Interrupt 
Arm (IA) bit in each channel's DMA Interrupt Arm 
Register (TDIAR and RDIAR). Figure 85 shows the 
format of these registers. If an IA bit is 1, the interrupt 


HAbort 


SAbort 


15 14 13 12 11 10 9 8 


logic sets the channel's IP bit when the corresponding 
status bit is 1. If an IA bit is 0, the corresponding 
status bit operates normally but has no effect on the 
channel's IP bit and thus cannot cause interrupts. 


DMA IP and IUS Bits 


Software can read, set, and clear the Interrupt 
Pending (IP) and Interrupt Under Service (IUS) bits 
for both DMA channels using the shareable Set and 
Clear DMA Interrupt Registers (SDIR and CDIR). 
Figure 86 shows the arrangement of these registers. 
Software can read the current state of the bits from 
the SDIR at any time. Writing a one, to one or more 
of the four active bit positions in the SDIR, sets the 
corresponding bit(s), while writing a zero has no 
effect. Writing a one, to one or more of the four active 
bit positions in the CDIR, clears the corresponding 
bit(s), while writing a zero has no effect. The registers 
are defined like this to avoid interactions between 
hardware setting the IP and |US bits and software 
clearing them. 


In addition, one of the encoded commands that can 
be written to the DMA Command / Address Register 
(DCAR) allows for a general exit from a DMA interrupt 
service routine, regardless of whether it serviced the 
transmit or receive channel. If software writes the 
Reset Highest DMA !US command (1000) to the 
DCmd field (DCAR15-12), the IUSC clears the 
highest-priority IUS bit that's set in the DMA section. 
Unfortunately, the command doesn't also clear the 
corresponding IP bit, so that an interrupt service 
routine has to do this explicitly for the particular 
channel that it's servicing. 


DMA IE Bits 


Software can read and write both channels’ Interrupt 
Enable (IE) bits in the less significant byte of the 
shareable DMA Interrupt Control Register (DICR). 
Figure 87 shows the DICR. If a channel's IE bit is 1, 
then the IUSC requests an interrupt when its IP bit is 
1 and its IUS bit is 0, provided that the channel's “IEI" 
from higher-priority types is true, and the DMA Con- 
troller's MIE bit (DICR15) is 1. 


| ss : EOA/ | EOB |HAbort! SAbort 
eserved (0) EOLIA! IA IA IA 
3 2 1 0 


7 6 5 4 


Figure 85. The Transmit and Receive DMA Interrupt Arm Registers (TDIAR and RDIAR) 


15 14 13 12 14 10 9 8 


TxDMA RxDMA| TxDMA 


7 6 5 4 3 2 1 0 


Figure 86. The Set and Clear DMA Interrupt Registers (SDIR and CDIR) 
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DMA-Controller-Level Interrupt Options 


Figure 87 also shows how the MSByte of the DMA 
Interrupt Control Register (DICR) includes four control 
bits that affect all interrupts from the DMA section. 
These bits are fully under software control and can be 
read or written at any time. 


The Master Interrupt Enable (MIE; DICR15) must be 
set to allow either of the DMA channels to request an 
interrupt. 


Whenever the Disable Lower Chain bit (DLC; 
DICR14) is 1, the |USC forces its IEO output low, so 
that devices further down the daisy chain can neither 
request interrupts nor respond to interrupt acknow- 
ledge cycles. 


lf the No Vector bit (NV; DICR13) is 1, the IUSC 
neither provides a vector nor drives the /WAIT//RDY 
pin, during an interrupt acknowledge cycle in which 
the highest-priority requesting type is one of the DMA 
channels. However, in such a case the IUSC still sets 
the IUS bit of the highest-priority requesting DMA 
channel. 


The Vector Includes Status bit (VIS; DICR12) 
controls whether the vector returned, during an 
interrupt acknowledge cycle in which the highest- 
priority requesting type is one of the DMA channels, 
identifies the channel or not. If VIS is 0, the IUSC 
returns the vector programmed by the host software 
unchanged for both channels. If VIS is 1, bits 2-1 of 
the returned vector are 10 for a Tx channel interrupt 
and 11 for an Rx channel interrupt. 


15 11 10 9 8 


14 13 12 


DMA Interrupt Vectors 


The vectors returned by the IUSC for interrupts from 
the DMA Controller are completely independent of 
those from the serial channel. Software can read and 
write interrupt vector information in the DMA Interrupt 
Vector Register (DIVR). This register is also the basis 
of the vector that the IUSC returns during an interrupt 
acknowledge cycle in which the highest-priority 
requesting type is one of the DMA channels. 

Figure 88 shows the format of the DIVR. Software 
can read and write the basic vector in its LSByte, and 
can read a modified version of the vector in its 
MSByte. (Writing the MSByte has no effect.) Bits 15- 
11 and 8 are the image of those in the corresponding 
bits of the LSByte. DICR10-9 are a TypeCode for the 
highest priority DMA interrupt type that has its IP bit 
set (the state of its IUS bit doesn't matter): 


TypeCode Meaning 


00 No DMA interrupt is pending 
Ol Reserved (will not be read) 
LO: “TH but: NOE. Rx Anterrupt 

11 Rx interrupt 


The state of the VIS bit (DICR12) has no effect on 
reading the DIVR. In reality, VIS simply determines 
whether the IUSC returns the MSByte or LSByte of 
the DIVR as the vector, during an interrupt acknow 
ledge cycle in which the highest-priority requesting 
type is one of the DMA channels. 


7 6 5 4 3 2 1 0 


Figure 87. The DMA Interrupt Control Register (DICR) 


Interrupt Vector 7-3 (RO) Type Cogs wwe Interrupt Vector (RW) 
(RO) (RO) 


15 14 13 12 11 10 S) 8 


7 6 5 4 3 2 1 0 


Figure 88. The DMA Interrupt Vector Register (DIVR) 
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7. Software Summary 


Just about everything important about the [USC has 
been said in previous chapters. This one simply pulls 
together some loose ends of interest to software 
types, as well as providing a unified reference to all 
the register fields. 


About Resetting 


The IUSC goes into an initial inactive state whenever 
external hardware drives the /RESET pin low. In this 
state, it stores the next data written to it in the Bus 
Configuration Register (BCR), whichever register 
address within the I|USC software uses for the write 
operation. Chapter 2 describes how the address used 
for the BCR write js actually important, in the sense 
that the address line connected to the S//D pin (the 
one that selects between the Serial Controller and 
DMA sections of the IUSC in normal operation) 
determines whether the |USC drives and receives the 
/WAIT//RDY pin as a "wait" or "acknowledge" hand- 
shake. 


Aside from requiring the BCR write, software can 
reset the IUSC just as thoroughly and completely as a 
hardware reset does. Resetting the Serial Controller 
in Chapter 4 describes how to do this, by first writing a 
1 to the RTReset bit in the Channel Command / 
Address Register (CCAR10), and then writing zeroes 
to the whole CCAR. Software can also fully reset the 
DMA channels, by writing the "Reset All Channels’ 
command (hex 90) to the MSByte of the DMA 
Command / Address Register (DCAR15-8). 


After either a hardware or a software reset, all 
register bits in the IUSC are zero except for the 
following: 


1. The following bits reflect the state of pins. The 
[USC treats these as inputs until and unless 


software programs them as outputs. 


MISR14 /RxC 

MISR12 /TxC 

MISR10 /RxREQ 
MISR8 /TxREQ 
MISR6 /DCD 

MISR4 /CTS 

PSR14 /PORT7 
PSR12 /PORT6 
PSR10 /PORTS 
PSR& /PORT4 
PSR6 /PORT3 
PSR4 /PORT2 
PSR2 /PORT1 
PSR1 /PORTO 
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2. The following bits are 1 because the TxFIFO is 
empty: 
TCSRO TxEmpty 
TICR13 (indicates 32 empty entries) 


Programming Order 


The |USC and other USC family members aren't as 
particular about the order in which software programs 
their register fields as are the members of Zilog's SCC 
family. Still, initializing registers in the wrong order 
can thoroughly confuse the IUSC's internal logic and 
make it do strange things. Always initialize the IUSC 
in the following order: 


1. Set the pin configurations in the IOCR and PCR. 
While it's OK to change the modes and even the 
direction of a signal dynamically, it should be fairly 
obvious that if you're going to use pins in certain 
ways, they ought to be pointing in the right 
direction before telling internal logic to use them. 
Select the clocking scheme in the CMCR and 
HCR. (It's OK to enable a BRG at this point if it's 
only used for clocking, but if it's used for interrupts 
it's probably best to wait until later.) 


Set up most or all of the other mode and contro! 
bits in the Transmitter, Receiver, DMA channels, 
etc., but don't enable anything to run or operate 
until all of the basic modes and controls are in 
place. This procedure avoids messy interactions 
when one internal unit is trying to signal another 
before the latter is ready to listen. 


Set up the initial Interrupt Arm bits and Interrupt 
Enable bits; it might be a good superstition to 
clear all the IP and IUS bits after doing this. 
Enable whichever units need to run and operate 
initially. Some units might not want to be enabled 
until later, like enabling the Transmitter and 
Receiver after a call is established. 


Finally, set the Master Interrupt Enable (MIE) bits 
in the serial controller and DMA sections. — In 
general, you want to do this last so that interrupt 
service routines can assume that everything's set 
up in its starting configuration. 


Using DMA to Initialize the Serial 
Controller 


Instead of initializing the serial controller and DMA 
channels together as described above, software can 
initialize the |USC's Transmit DMA channel first and 
then use it to initialize the serial controller. To do this: 


1. Initialize the shared DMA registers DCR and 
BDCR to match the system hardware and 
software configuration. There shouldn't be any 
need to use interrupts for this operation, but it 
might be a good idea to set up the DICR and 
DIVR as well. 


2. Program the MSByte of the TDCMR appropriately 
for the initializing transfer. Single Buffer mode 
should suffice. 


3. Program the TAR with the address of a sequence 
of bytes or 16-bit words that will initialize the serial 
controller. If there's only an 8-bit bus, structure 
this string as a series of byte pairs. The first byte 
of each pair goes into the LSByte of the Channel 
Command / Address Register (CCAR) to identify 
the destination (register address) of the second 
byte of the pair. If there's a 16-bit bus, structure 
the sequence as pairs of 16-bit words. The first 
word of each pair goes into CCAR to identify the 
destination of the second word of the pair. 


4. Arrange the string/sequence to initialize the serial 
controller registers in the order described in the 
previous section. Make the ChanLoad bit (bit 7) 
of the first byte or word of each pair be 1, except 
make it 0 in the last entry of the sequence. If the 
RegAddr field in that last entry is non-zero, that is, 
if it doesn't point to the CCAR, the IUSC will fetch 
the second byte or word of the last pair and write 
it into the indicated register before finishing the 
initializing operation. If the RegAddr is zero, the 
l\USC stop without fetching a following byte or 
word, 


5. Program the TDCMR with the length of the initial- 
izing string. This should include at least the first 
byte or word of the last entry, and optionally the 
second word or byte, as described above. 


6. Write a “Start Tx Channel" command including 
MBRE=1 (hex 21) to the MSByte of the DMA 
Command / Address Register (DCAR). 


7. Write a "Trigger Channel Load DMA" command 
(hex 20) to the MSByte of the CCAR. 


8. Assuming the processor is set up to grant use of 
the bus to the IUSC, the operation should 
complete very quickly. This should be verified by 
checking the LSByte of the TDCMR for hex 04 
(End of Block). 


Register Reference 


The following pages include all of the fields in all of 
the registers in the IUSC, including both the serial 
controller and DMA sections. They are arranged in 
alphabetical order by register name, like Table 2 in 
Chapter 2. (if you want to look up a register by its 
address/register number, look in Table 1 in Chapter 2 
and then come back here...) 


Register Addresses 


These are located to the right of the name of each 
register on the following pages, and are shown as 


Ss d b aaaaa, where: 


s is the address bit connected to the S//D pin 
| (O=DMA, 1=serial); 
d is the address bit connected to the D//C pin, 


or the bit in DCAR7 (O=serial control regs or 
DMA Tx, 1=serial Data regs or DMA Rx); 

b is 1 for a byte access on a 16-bit bus (it's just 
shown as "b" in all cases, like a placeholder); 


aaaaa is the actual register address, from AD5-1, 
AD13-9, CCARS5-1, or DCAR5-1. 


Conditions/Context 


Entries in this column indicate the conditions under 
which descriptions to their right apply or can validly be 
used. If an entry is blank, the description to the right 


always applies. 


Description 


Often entries in this column consist of one or more 
subentries of the form 'value=description". If some 
possible values aren't shown, it may mean they are 
reserved (and should not be written) or that they will 
never be read. Or, particularly for single Read-Write 
bits, if the other case is obvious, it's left out. For 
example, for an entry like "1=dog is dead" we didn't 
feel obliged to add "O=dog is alive". 


The following abbreviation is used in some entries in 

this column and "Conditions/Context": 

= this "assignment operator" indicates that 
the value on its right is written to the field 
or bit on its left. 
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RW Status 


This column includes the following codes for each 
register field: 


RW 
RO 
ROC 


WO 


WOC 


R,W1C 


R,W1U 


The field is fully under the control of 
software, and can be read and written. 

The field is read only; writing to it has no 
effect. 

The bit is read-only; the |USC clears it 
automatically after software reads it as 1. 
The field is write-only; reading it will either 
return zeroes or an unrelated item that's 
described next in the list. 

The field is write only. After using its value 
the IUSC will clear it to zero, so that it 
points back to the indirect address register. 
The bit is set by the IUSC hardware, 
writing a 1 to it clears it. 

The bit is controlled by the IUSC hardware, 
writing a 1 to it “unlatches'’ it. 
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Burst/Dwell Control Register (BDCR) Register Address 0 x b 01001 


15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Name /Context Status 

BDCR15-8 |Maxxfers O=no effect; RW |5: Bus Occupancy Throttling 

1-255=maximum number of bus cycles/transfers 

the DMA channels will do 


(p.104) 
BDCR7-0 |MaxCLKs O=no effect; 







































1-255=DMA channels limited to 8-2040 CLK 





periods per bus grant 
Bus Configuration Register (BCR) No Address (First Write after /RESET) 
ee os 
5 4 3 2 1 0 


15 14 13 1 


2 
Bit(s) Fiela/Bit Description Ref Chapter: Section 
Name /Context Status 
BCR15 SepAd 8-bit bus|1 if AD13-8 carry register addresses WO |{2: Bus Configuration Registe 
16-bit bus| Must be 0 (pp.14-15) 


BCR5-4 |[AckMode 00=sample /INTACK at start of each slave cycle 
01=single pulse on /INTACK 
11=double pulse on /INTACK 


11 10 9 8 7 6 














O=drive /BUSREQ open-drain, sample it first 
1=drive /BUSREQ totem pole (full time 
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Channel Command/Address ngrster (CCAR) Register Address 1 0 b 00000 





Chan 


11 


Name /Context situs 


CCAR15-12|RTCmd 00000=no operation 4: Commands (pp.70-74) 
00001 =Reserved 
00010=Reset Highest Serial IUS 
00100=Trigger Channel Load DMA 
00101=Trigger Rx DMA | 
00110=Trigger Tx DMA 
00111=Trigger Rx and Tx DMA 
01001=Purge Rx FIFO 
01010=Purge Tx FIFO 
01011=Purge Rx and Tx FIFO 
01101=Load RCC 
01110=Load TCC 
01111=Load RCC and TCC 
10001=Load TCO 
10010=Load TC1 
10011=Load TCO and TC1 | 
10100=Select Serial Data LSBit First 
10101=Select Serial Data MSBit First 
10110=Select D15-8 First 
10111=Select D7-0 First 
11xxx=Reserved 








3: The RxD and TxD Pins 
(pp.31-32) 


00=normal mode: Tx and Rx are independent 
01=echo RxD to TxD 











CCAR10 pee 1= ee eae Serial Controller in software Reset state ee Resetting the Serial 
O=release it ee ean Reset state Controller (p.74 
10=Local Loop TxD to RxD 


CCAR9-8 saeco RW 
scene Channel Loa paafon isinternal Local Loop 


Load DMA jon lalate cee aD it Serial Controller (p.126 
= =access MS or LS byte of register _|(oP8-19) 
register address for next access to CCAR (see 


Table 1 


CCARO U//L 1=access MSByte of reg selected by RegAddr 
O=access LSByte or whole 16-bit register 
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Channel Command/Status Register (CCSR) Register Address 1 0 b 00010 


RCCF DPLL | DPLL | DPLL On Loop Ctr 
15 14 13 12 11 10 





9 8 7 6 5 


Name /Context 

















4 3 2 1 0 
Ref Chapter: Section 
Status 
RCCF Ovtlo 1=RCC FIFO overflow (4+1 frames) ia 4: DMA Support Features: 
Enabled The RCC FIFO (p.68) 


RCCF Avail { =~: { 1= RCC FIFO not emot 
TE heated a dl 








Clear RCCF a 1=purge RCC FIFO, clear RCCF Ovtlo and WO 
RCCF Avail to 0 


DPLL Sync 1=DPLL in sync R,W1C/3: More About the DPLL 
CCSR11 _|DPLL2Miss 1=DPLL has seen 2 consecutive missing clocks |R,W1C](pp.30-31) 


iscscnale 
ICCSR12__| 
DPLL1Miss 1=DPLL has seen a missing clock R,W1C 
CVOK=0 
DPLL Edge |. OO=DPLL resyncs on rising and falling edges RW 
NRZj/01=DPLL sees rising edges only; 
modes] 10=DPLL sees falling edges only; 
onl 
CCSR7 OnLoop 
















4: Slaved Monosync Mode 
(p.53) 
4: HDLC/SDLC Loop Mode 
(pp.57-58) 


aa HDLC/SDLC Loop Mode 
00.57-58 


RW 1{3: Transmit and Receive 


CCSR15 
CCSR14 
CCSR13 
CCSR12 
CCSR10 
CCSR9-8 
CCSR6 LoopSend H/SDLC| 1=Transmit actively sending; 
Loop |0=Transmit repeating Receive 
CCSR5 CtrBypass O=route CTR1-0 outputs to Rx/TxCLK selection, 
BRG's, /RxC, /TxC output selection Clocking: Using PORTO-1 for 
Bit Clocking (p.25 
CCSR4-2 |TxResidue H/SDLC, | 000=last character of Transmit frame contains 8} RW {4: HDLC/SDLC Mode: 
H/SDLC] bits; 001-111= last character contains 1-7 bits Frame Length Residuals 
Loop 0p.48-49 









1=route PORT1-0 pins direct to these uses 
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Channel Control Register (CCR) Register Address 1 0 b 00011 
TxCtriBik Tx Pre- RxStatBlk Rx Reserved (0) 
trig_| ambie Trg 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Name /Context Status 
CCR15-14 |TxCtriBlk 00=don't use Transmit Control Blocks; RW |4: DMA Support Features: 
pp.68-69 
CCR13 Wailt4TxTrig Sync} 1=hold Transmit DMA Request between frames 4: Synchronizing Frames/ 
DMA" command ; 
CCR12 Flag H/SDLC,|1=send Flags as Preamble 4: Between Frames, 
Preamble CCR9-8 Messages, or Characters 
=01 0p.76-78 
CCR11-8 |TxShaveL Async,|shave the number of Stop bits 4: Asynchronous Mode 
by (15 minus the value in this field)/16 bit times 
OO0=send 8-bit Preamble; 01=16-bit: 4: Between Frames, 
Preamble | 10=32-bit; 11=64-bit Messages, or Characters 
00=all-zero Preamble; 01=all ones or Flags; 
Preamble|10=101010...; 11=010101... 


(pp. 76-78) 
CCR7-6 RxStatBlk 00=don't use Receive Status Blocks: 
Ext Sync,|01=use 16-bit RSB's; 
T. Bisync,|10=use 32-bit RSB's 


CCR5 Wait4RxTrig Sync} 1=hold Receive DMA Request between frames/ 
messages until software issues "Trigger Rx 
DMA" command 



















































































4: DMA Support Features: 
Receive Status Blocks 
(pp.69-70) 









4: Synchronizing Frames/ : 
Messages with Software 
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Channel Mode Register (CMR) Register Address 1 0 b 00001 


15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Because the content of the SubMode fields depends on the Mode fields, the following descriptions are grouped by 
mode. TxSubMode and RxSubMode bits that are not shown for a particular Mode value are Reserved in that mode 
and should be programmed with zeroes. 


Name /Context 

CMR11-8 [TxMode | _———*|0000=Asynchronous— 
MR15-14 |TxSubMode | TxMode=0|00=send one stop bit; 01=two stop bits; 
10=1 shaved stop bit (per CCR11-8); 
11=2 shaved stop bits 


00=16 TxCLKs/Tx bit; 01=32 TxCLKs/Tx bit; 
















CMR13-12 


CMR3-0__|RxMode_ | 
CMR5-4 RxSubMode | RxMode=0/00=16 RxCLKs/Rx bit; 01=32 RxCLKs/Rx bit: 
10=64 RxCLKs/Rx bit 





10=64 TxCLKs/Tx bit 


0000=Asynchronous 











CMR11-8 |TxMode | _—=—|0001=Reserved — EEE 
CMR3-0  |RxMode |  —— |0001=External Sync 4: External Sync Mode (p.50 
beat saat 





fo) o] a 
e 


CMR11-8 4: Isochronous Mode (p.47) 
CMR14 
CMR3-0__[RxMode_ | —s—s«*([0010=2=Isochronous. ss —“‘;‘“C;CSC*d*rtS:CRRWW CY 
CMR11-8 |TxMode | |0011=3=Async w/Code Violations (1553B 4: Async w/Code Violations 





O 
s 
= 
oi 
rs 
— 
x< 
ey) 
Cc 
oO 
= 
oO 
a. 
@ 
+ 
x 
= 
2) 
Q 
@ 
G 
Oo 
O 


=send one stop bit; 01=two stop bits; 
10=no stop bits 
0=Tx length <= 8 bits per TxLength (TMR4-2); 

1=Tx length is 8 more than indic. by TxLen 
CMR12 O=send Data words; 


1=send Command/Status words 
CMR3-0 


0011=3=Async w/Code Violations (1553B RW 
CMR4 RxSubMode | RxMode=3] 0=Rx length <= 8 bits per RxLength (RMR4-2); 
‘ é 


CMR11-8__|TxMode_ | —_—*(|0100=4=Monosyne RW 


TxSubMode | TxMode=4} 1=send CRC on Tx Underrun RW _ |Modes 
CMR13 1=send Preamble before opening Sync 
CMR12 O=send 8-bit Syncs; 
1=send Syncs per TxLength 


CMR3-0 |RxMode | —— |0100=4=Monosync 


CMRS5 RxSubMode | RxMode=4] 1=strip received Syncs; RW 
O=include them in RxFIFO and CRC calculation 
CMR4 O=expect 8-bit Syncs; 
1=expect Syncs per RxLength 
T 


CMR11-8_ |TxMode |  ————[0101=5=Bisync 


CMR15 TxSubMode | TxMode=5} 1=send CRC on Tx Underrun RW 
CMR14 =send closing/idle SYNs from TSR15-8; 

1=send closing/i - - 
CMR13 
CMR12 O=send 8-bit Syncs; 

1=send Syncs per TxLength 


CMR3-0 _|RxMode | _—_—=«i{0101=5=Bisync 


CMR5 RxSubMode | RxMode=5| 1=strip received Syncs; RW 
O=include them in RxFIFO and CRC calculation 
CMR4 O=expect 8-bit Syncs; 
1=expect Syncs per RxLength 
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Mode (pp.48-50) 









CMR13 





































QO 
= 
= 
a 


Channel Mode Register (CMR) -- Continued 


Because the content of the SubMode fields depends on the Mode fields, the following descriptions are grouped by 
mode. TxSubMode and RxSubMode bits that are not shown for a particular Mode value are Reserved in that mode 
and should be programmed with zeroes. 


/Context Status 
R11-8 0110=6=HDLC/SDLC W_ 14: HDLC/SDLC Mode 


: i W_| (pp.54-56) 


O 
i 
= 
3 
® 
a2 


A 
= 
x 
op) 
os 
oy 
= 
ve) 
Qa 
@ 
S| 
x 
= 
"e) 
ron 
@ 
ro) 
ro) 
ro) 
o 
® 
5 
ro’ 
N 
o. 
- 
> 
o 
° 
a4 
fe) 
5 
4 
Cc 
5 
a. 
@ 
=x 
c 
ze 






QO 
<= 
= 
a 
Be) 


01=send 15-bit Abort; 10=send Flag; 
11=send CRC then Flag 


1=send Preamble before opening Flag 


1=consecutive idle Flags share a 0 


CMR13 
CMR12 


CMR3-0 


CMR7-4 RxSubMode | RxMode=6| xx00=no Address or Control field handling; 
xx01=1-byte Address only; 
x010=1-byte Address, 1-byte Control; 
x110=1-byte Address, 2-byte Control; 
0011=Extended Address, 1-byte Control; 
0111=Extended Address, 2-byte Control; 
1011=Extended Address, Control >= 2 bytes; 


1111=Extended Address, Control >= 3b 


CMR11-8 |TxMode | _ |0111=7=Transparent Bisync 
CMR15 xSubMode | TxMode=7| 1=send CRC on Tx Underrun 
CMR14 O=send closing/idle SYNs; 












4: Transparent Bisync Mode 
(pp.51-52) 









| Q}D 


1=send closing/idle DLE-SYNs 


1=send EBCDIC 
CMR3-0__|RxMode_ | —s—s*([0111=7=TransparentBisync 


T 
[RxMode 
CMR4 RxSubMode | RxMode=7 1! 0=look for ASCII control characters; 
1=look for EBCDIC 


CMR11-8 |TxMode |  —— |1000=8=Nine Bit 


CMR15 TxSubMode | TxMode=8| 0=send 9th bit 0 (data); 
1=send 9th bit 1 (address 
CMR14 O=send eight data bits; 
1=send seven data bits plus pari 
CMR13-12 00=16 TxCLKs/Tx bit; 01=32 TxCLKs/Tx bit; 


10=64 TxCLKs/Tx bit 
CMR3-0 1000=8=Nine Bit 


ec eed 
CMRS5-4 xSubMode | RxMode=8]| 00=16 RxCLKs/Rx bit; 01=32 RxCLKs/Rx bit; 
10=64 RxCLKs/Rx bit 
Meee ae tae 


CMR13 
CMR12 


4: Nine Bit Mode (pp.47-48) 







R 
CMR11-8 1001=9=802.3 (Ethernet 
CMR15 TxSubMode | TxMode=9/ 1=send CRC on Tx Underrun 
CMR3-0  |RxMode |  __ |1001=9=802.3 (Ethernet 


CMR4 RxSubMode | RxMode=9]0=receive all frames; 
1=match 16-bit Destination Address vs. RSR 


CMR11-8 Pveee 101x=10-11=Reserved 
- 
CMR11-8 |TxMode | —Ss——([1100=12=SlavedMonosync (| SRW 
CMR15___|TxSubMode | TxMode RW 
1=send a(nother) message 
CMR12 O=send 8-bit Syncs; 
1=send Syncs 


CMR3-0  |RxMode 
Monosyne with TxMode=1100=12 


4: 802.3 (Ethernet) Mode 
(pp.53-54) 


DQ} |) pulps JD | 


4: Slaved Monosyne Mode 


: Oo 
<< 
D 
Ww 
Oo 





133 


Channel Mode Register (CMR) -- Continued 
Name /Context Status 


CMR3-0 
CMR11-8 |TxMode |  —— 1|1110=14=HDLC/SDLC Loop 4: HDLC/SDLC Loop Mode 
(pp.57-58) 


CMR15-14 |TxSubMode TxMode | 00=send 7-bit Abort on Tx Underrun; 
ae =14/01=send 15-bit Abort; 10=send Flag; 
11=send CRC then Flag 
(initially) O0= Transmit disabled; 1=insert into 
; (once inserted) O=repeat Rx to Tx; 1=send 
11111101111111...); O=(11111100111111... 


CMR3-0 ee | 1110=14=Reserved (use RxMode=0110=6= 












fe 




























HDLC/SDLC with TxMode=1110=14 


CMR11-8 1111=15=Reserved 
CMR3-0 


Clear DMA Interrupt Register (CDIR) Register Address 0 x b 01101 





J JD wipe) 








| TxDMA RxDMA!TxDMA 
15 14 13 12 11 10 9 8 7 6 5 3 2 { 0 





Bit(s) 











4 
Name /Context Status 
CDIR9 IRXDMAIUS | ————sd 1=clear Rx DMA IUS bit; O=no change WO. |6: DMA IP and IUS Bits 
TTXDMAIUS | ——si[ 1 =clear Tx DMA IUS bit; O=no change (p.122) 
ee ed 
ae 


















RxDMA IP . 1=clear Rx DMA IP bit; O=no change 


TxDMA IP 1 


elle) 
eile, 
| 
=| 





CDIRO =clear Tx DMA IP bit; O=no change 
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Ciock Mode Control Register (CMCR) 


Register Address 1 0 b 01000 


CTR1Src CTROSrc paroisre BRGOSrc DPLLSre TxCLKSre RxCLKSre 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Bit(s) Field/Bit oo a re RW |Ref Chapter: Section 
Name /Context Status 


00=CTR1 disabled; 
01=CTRI1 input is PORT1/CLK1; 


10=/RxC 

00=CTRO disabled; 

01=CTRO input is PORTO/CLKO; 
10=/RxC 
00=BRG1 input is CTRO output or PORTO; 
01=CTRI1 output or PORT1; 

10=/RxC pin; 11=/TxC pi 

00=BRGO input is CTRO output or PORTO; 
01=CTR1 output or PORT1; 

10=/RxC pin; 11=/TxC pin 
00=DPLL input is BRGO output; 
01=BRG1 output; 10=/RxC pin; 11=/TxC 
000=no TxCLK (Transmit disabled); 
001=TxCLK is /RxC; 010=/TxC; 
011=DPLL Tx output; 

100=BRGO output; 101=BRG1 output; 
110=CTRO output or PORTO; 
111=TxCLK is CTR1 output or PORT1 
000=no RxCLK (Receive disabled); 
001=RxCLK is /RxC; 010=/TxC; 
011=DPLL Rx output; 

100=BRGO output; 101=BRG1 output; 
110=CTRO output or PORTO; 
111=RxCLK is CTR1 output or PORT1 


CMCR15-14|CTR1Src 
CMCR13-12}|CTROSrc 
CMCR11-10}|BRG1Src 























CMCR9-8 |BRGOSrc 
CMCR7-6 |DPLLSrc 


CMCR5-3 |TxCLKSre 
CMCR2-0 |RxCLKSrc 
























135 


RW |3: Tx and Rx Clocking: 


CTRO and CTR1 (p.25) 


3: Tx and Rx Clocking: 
The Baud Rate Generators 
(pp.25-27) 





Intro to the DPLL (p.27 
3: Tx and Rx Clocking: 
TxCLK and RxCLK Selection 


(p.28) 





Daisy Chain Control Register (DCCR) Register Address 1 0 b 01101 
IUS Op RS TS | TD IP Op TS TD 
(WO) lUS US lus (WO) IP IP 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Name /Context Status 
6: Receive Status Interrupt 
TS |US read| 1=Transmit Status interrupt under service | RO |6: Interrupt Pending and 
O=no change 6: Transmit Data Interrupts 

























DCCR13 read| 1=Receive Status interrupt under service 6: Interrupt Pending and 
write} 1=set or clear Receive Status IUS per IUS Op; 
O=no change 
| RO |6: Interrupt Pending and 
O=no change 6: Tx Status Interrupt Sour- 


wo. |Under Service Bits (p.120); 
DCCR12 j{RDIUS read| 1=Receive Data interrupt under service 
write| 1=set or clear Receive Data IUS per |US Op: Wo |Under Service Bits (p.120); 
6: Rx Data Interrupts (p.116) 
TD IUS read| 1=Transmit Data interrupt under service | RO |6: Interrupt Pending and 
write| 1=set or clear Transmit Data IUS per |US Op; Under Service Bits (p.120); 


DCCR15-14)IUS Op Ox=no operation; WO |6: Interrupt Pending and 
10=clear IUS bits selected by 1s in DCCR13-8; Under Service Bits (p.120) 
11=set IUS bits selected by 1s in DCCR13-8 

RS |uS | RO | 
( ) 
Sources and IA Bits (pp.115- 
write| 1=set or clear Transmit Status IUS per IUS Op; Under Service Bits (p.120); 


pp.118-119 


lOP US read| 1=I/O Pin interrupt under service | RO |6: Interrupt Pending and 
write! 1=set or clear I/O Pin IUS per IUS Op; Wo. |Under Service Bits (p.120); 
O=no change 6: 1/0 Pin Interrupt Sources 



























Misc |US read| 1=Miscellaneous interrupt under service | RO |6: Interrupt Pending and 

write| 1=set or clear Miscellaneous IUS per |US Op; | WO |Under Service Bits (p.120); 
O=no change 6: Miscellaneous Int. Source 

and IA Bits (pp.119-120 


00=no operation; WO |6: Interrupt Pending and 
01=clear IP and IUS bits sel by 1s in DOCRS5-0; Under Service Bits (p.120) 





10=clear IP bits selected by 1s in DCCRS5-0; 
11=set IP bits selected by 1s in DCCR5-0 


read| 1=Receive Status interrupt pending | RO |6: Interrupt Pending and 
write| 1=set or clear Receive Status IP/IUS per IP Op;| WO |Under Service Bits (p.120); 
O=no change 6: Rx Status Interrupt Sour- 








read 
write 


1=Receive Data interrupt pending 
1=set or clear Receive Data IP/IUS per IP Op; 


6: Interrupt Pending and 
Under Service Bits (p.120); 
6: Rx Data Interrupts (p.116) 


| RO | 6: Interrupt Pending and 
Under Service Bits (p.120); 
6: Tx Status Interrupt Sour- 


WO 
ces and IA Bits (pp.116-118) 


| RO |6: Interrupt Pending and 


Wo |Under Service Bits (p.120); 
6: Transmit Data Interrupts 
read| 1=I/O Pin interrupt pending | RO |6: Interrupt Pending and 
write} 1=set or clear I/O Pin IP/IUS per IP Op; wo |Under Service Bits (p.120); 
O=no change 6:1/O Pin Interrupt Sources 
| RO |6: Interrupt Pending and 


Under Service Bits (p.120); 







TS IP read 
write 









TD IP read 
write 


1=Transmit Data interrupt pending 


1=set or clear Transmit Data IP/IUS per IP Op; 
O=no change 









oO Oo O Oo O Oo O O O 
@) QO QO QO ‘@) (2) QO @) @) 
QO Q) '@) @) QO @) QO Q @) 
Bs) wD D D D DD D DD DD 
nN [¢*) BS on ~N“N ao oO = _ 

do ° 7 






read 
write 


1=Miscellaneous interrupt pending . 


1=set or clear Miscellaneous IP/IUS per IP Op; 
O=no change 6: Miscellaneous Int, Source 


and IA Bits (90.119-120 


O O 
O O 
QO QO 
D D 
[ [> } —_— 
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DMA Array Count Register (DACR) Register Address 0 x b 00100 


15 13 12 11 10 9 8 z 6 5 3 2 1 0 









4 
Name /Context Status 
DACR7-4 |RALCnt Array or|reflects the Rx DMA channel's progress while 5: Array and Linked-List 
Linked List|fetching array or list information. See Ref text 









14 
Fetching Status (pp.104-105) 
DACR3-0 |TALCnt reflects the Tx DMA channel's progress while 


fetching array or list information. See Ref text. 
DMA Command/Address Register (DCAR) Register Address 0 x b 00000 
ee [men Bele] ee | 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


DCAR15-12 treating all of DCAR15-9 as a single field: 5: Commands and 
DCARQ Rx/Tx Cmd 0000000=Null (no operation); /BUSREQ Enable (pp.95-96) 


0001000=Reset Tx Channel: 

0001001=Reset Rx Channel; 

0010000=Start Tx Channel; 

0010001=Start Rx Channel; 

0011000=Start/Continue Tx Channel; 
0011001=Start/Continue Rx Channel; 

0100000=Pause Tx Channel; 

0100001=Pause Rx Channel; 

0101000=Abort Tx Channel; 

0101001=Abort Rx Channel; 

0111000=Start/Init Tx Channel; 

0111001=Start/Init Rx Channel; 

1000000=Reset Highest DMA IUS; 

1001000=Reset All Channels; 

1010000=Start All Channels; 

1011000=Start/Continue All Channels; 

1100000=Pause All Channels; 

1101000=Abort All Channels; 

1111000=Start/Init All Channels 

1=enable Bus Requests by the DMA channels: 
O=block Bus Requests by the DMA channels 
1=RegAdar refers to a Rx DMA register; WOC /2: Register Addressing 
O=use D//C to select Rx/Tx register (pp. 15-19) 








WOC 
1=access MSByte of reg selected by RegAddr; | WOC 
O=access LSByte or whole 16-bit register 
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DMA Control Register (DCR) Register Address 0 x b 00011 








Name /Context Status 
DCR15-14 a i 00=Tx DMA has priority for bus access; RW_[5: Inter-Channel Operation — 
01=Rx DMA has priority; and Priority (pp.99-100) 
IOCR13.—«([PreEmpt. | ~~—_ | 1=higher-priority channel can seize bus control 


DCR12 ALBVO O=addresses/counts are Little-Endian (Z80/intel) 5: Format of Binary Values 
Linked List| 1=Big Endian (Z8000/680x0 in Arrays/Lists (pp.96-98 


CR11-10 |ReArbTime 00=select channel at start of each grant, both 5: Inter-Channel Operation 
channels can use the bus in one grant; 
01=channel keeps selection until its request is 
gone; then other channel can use the bus in the 
same grant;: 
10=select channel at start of each grant, only 
one channel can use the bus 

































D : 
and Priority (pp.99-100) 
DCR5 MinOff39 1=minimum bus re-request time is 39 CLKs; 
0=7 CLKs 


DCSDOut 1=drive D//C pin low for Tx DMA, high for Rx 


| DMA and drive S//D low for array/list access, 
1Wai 
DCR1-0 AdadrSeg 


DMA Interrupt Control Register (DICR) Register Address 0 x b 01100 
a a oe 
14 13 12 


15 1 10 9 8 7 6 5 4 3 2 1 0 
Name /Context Status 
RW 


DICR15 {MIE i 1=enable interrupts from DMA channels 6: DMA-Controller-Level 
1 


=disable IEO from IUSC Interrupt Options (p.123) 


=don't provide a vector during |Ack cycles 


ne | 
DICR12 1=include TypeCode in DMA interrupt vectors; 
| O=return vector as software wrote it to DIVR7-0 


5: Bus Occupancy Throttling 
D.104 


2: DMA Cycle Options 
(pp.22-23) 
5: Bus Cycle Options (p.101) 


















high for data; 






O=don't drive D//C, S//D pins 


1=add one Wait state to all DMA cycles 


oe ee 
1=present /UAS and MS16 of address in every 
cycle; O=only when necessa 









00=32-bit address incrementing/decrementing; 
10=incr/decr affects only LS 16 address bits; 
11=incr/decr affects only LS 24 address bits 


5: Address Sequencing 
(p.96) - 










1=Rx DMA interrupt enable(d 
1=Tx DMA interrupt enable(d 
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DMA Interrupt Vector Register (DIVR) Register Address 0 x b 01010 


Interrupt Vector 7-3 (RO) ey BO) Interrupt Vector (RW) 
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
j RW |Ref Chapter: Section 
Status 
















Description 


15 
joe 
Name /Context 
DIVR15-11 ae read|as software wrote DIVR7-3 6: DMA Interrupt Vectors 
(pp.122-123) 


DIVR10-9 |TypeCode | DIVR15-8,|highest pending interrupt type: 


or [Ack w/}00=no DMA type pending; 
DIVR8 


VIS=1|10=Tx DMA (no Rx DMA); 
ees 
- _ 


(DICR12) 
Hardware Configuration Register (HCR) Register Address 1 0 b 01001 


crm [toe ons | ran [ meee [pons nee ln 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 { 0 
Name /Context Status ee 
pa jee a! 00=CTRO divides by 32; RW 13: Tx and Rx Clocking: 
01=/16; 10=/8; 11=/4 CTRO and CTR} (p.25) 
peue ere O=CTRODiv determines CTR1 divisor: 
1=DPLLDiv determines CTR1 divisor 
0p,30-31 . 
Intro to the DPLL (p.27 


HCR11-10 |DPLLDiv fo 00=DPLL divides by 32; 01=/16; 10=/8; 
HCRQ-8 DPLLMode OO0=disable DPLL; 3: More About the DPLL 
01=run DPLL for NRZ modes; (pp.30-31) 
10=run DPLL for Biphase-Mark or -Space; 
11=run DPLL for either Biphase-Level mode 
Easel 





WJ 
















as software wrote DIVRO 

read/write; basic 8-bit DMA interrupt vector 
DIVR7-0, 
or |Ack w/ 















Ref Chapter: Section 






















11=don't use for DPLL (/4 for CTR1 
HCRS5 BRG1S 3: Tx and Rx Clocking: 


HCRO BRGOE 


1=enable BRG1 The Baud Rate Generators 


pp.2orel. 


1=BRGO single cycle mode; O=continuous 3: Tx and Rx Clocking: 


1=enable BRGO The Baud Rate Generators 
Dp.25-27 


1=BRG1 single cycle mode; O=continuous 





— 139 


Input/Output Control Register (IOCR) 





15 14 13 1 









Ox=/CTS pin is low-active Clear To Send input; 
10=drive /CTS Low; 11=drive /CTS High 
00=/DCD is low-active Rx Carrier Detect input; 
01=/DCD is low-active Rx Sync Detect input; 
10=drive /DCD Low; 11=drive /DCD High 
00=/TXREQ pin is an input; 
01=drive /TxREQ with Transmit DMA Request; 
10=drive /TXREQ Low; 11=drive /TxREQ High 
00=/RxREQ pin is an input; 
01=drive /RxREQ with Receive DMA Reauest; 
10=drive /RXREQ Low; 11=drive /RxREQ High 
00=drive /TxD with Transmitter output; 
01=release /TxD to high impedance; 
10=drive /TxD Low; 11=drive /TxD High 
000=/TxC pin is an input; 
001=drive /TxC with TxCLk; 

010=drive /TxC with Transmit char clock; 
011=drive /TxC with Transmit Complete; 
100=drive /TxC with output of BRGO; 
101=drive /TxC with output of BRG1; 
110=drive /TxC with output of CTR1; 
111=drive /TxC with Tx output of DPLL 
000=/RxC pin is an input; 
001=drive /RxC with RxCLk; 

010=drive /RxC with Receive char clock; 
011=drive /RxC with /RxSYNC; 
100=drive /RxC with output of BRGO; 
101=drive /RxC with output of BRG1; 
110=drive /RxC with output of CTRO; 
111=drive /RxC with Rx output of DPLL 





lIOCR15-14 };CTSMode 
OCR13-12 |DCDMode 


| aa 
IOCR11-10 | TxRMode 
IOCR9-8 RxRMode 




































l|OCR7-6 TxDMode 


lOCR5-3 TxCMode 
lIOCR2-0 RxCMode 
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Register Address 10b 01011 


4 


2 11 
Name /Context Status 







CTSMode DCDMode TxRMode RxRMode | TxDMode | TxCMode RxCMode 


3 2 0 
| ) 


3: The /CTS Pin (pp.34-35 


1 
3: The /DCD Pin (pp.33-34) 









3: The /RXREQ and /TxREQ 
Pins (pp.35-36) 






3: The /RxD and /TxD Pins 
(pp.31-32) 





3: The /RxC and /TxC Pins 
(p.35) 


Interrupt Control Register (ICR) Register Address 1 0 b 01100 
IE Op TS TD 
15 14 13 12 1 10 9 8 7 6 5 4 3 2 1 0 
Field/Bit Description RW |Ref Chapter: Section 
Name /Context Status 
CR15 MIE —~—~*|~——s«&' 1 enable interrupts from this serial controller 6: Serial Interrupt Options 
CR14 DLC —=—-« | ~—Ssdd: A sdisable Interrupt Enable Out (IEO (pp.120-121) 
CR13 INV. ss |-———s A don't return a vector during /INTACK cycle 
ICR12-9 VIS 
1110=vectors include status only for RS 
1111=interrupt vectors never include status 


R 
- ant he Ox=no operation; 6: Serial Interrupt Enable Bits 
10=clear the IE bits selected by 1s in ICR5-0; 
11=set the IE bits selected by 1s in ICR5-0 
RS IE read| 1=Receive Status interrupt enabled | RO | 
ee ve 1=set or clear Receive Status IE per IE Op; 
O=no change 
read| 1=Receive Data interrupt enabled 
1=Transmit Status interrupt enabled | RO | 
1=set or clear Transmit Status IE per IE Op; 
read|1=1/O Pin interrupt enabled | RO | 
write] 1=set or clear I/O Pin IE per IE Op; ace 
OQ=no change 
1=Miscellaneous interrupt enabled | RO | 
write 














Bs) 
= 


Oxxx=interrupt vectors never include status; 
100x=interrupt vectors always include status; 
1010=vectors include status except for Misc; 
1011=vectors include status only for TD, TS, 
RD and RS 

1100=vectors include status only for TS, RD, 
and RS 

1101=vectors include status only for RD and RS 






























= 







= 
O 


= 
O 





| RO_| 
1=set or clear Receive Data IE per IE Op; WO 
OQ=no change 
write 
O=no change 
1=Transmit Data interrupt enabled | RO | 
write} 1=set or clear Transmit Data IE per IE Op; 
O=no change 
1=set or clear Miscellaneous IE per IE Op; 
O=no change 





= 
O 






mo D DV Be) ps) wD we) =~ 
Oo = NO to B on N Ay 
fo) 
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Interrupt Vector Register (IVR) Register Address 1 0 b 01010 


Interrupt Vector7-4 (RO) Type Code (RO) ro Interrupt Vector (RW) 
12 4 3 2 1 0 


11 


Bit(s) Field/Bit Description Ref Chapter: Section 
| Name /Context Rag 
IVR15-12 po read| as software wrote IVR7-4 6: Serial Interrupt Vectors 


(p.121) 
IVR11-9 TypeCode IVR15-8,| highest pending interrupt type: 


or |Ack w/|000=no interrupt type pending; 
highest] 001=Misc; 

IVR8 as 

: 7 











































pending} 010=1/O Pin; 
type|011=Transmit Data; 
enabled by| 100=Transmit Status; 
ICR12-9| 101=Receive Data; 
110=Receive Status 
read/write| basic 8-bit interrupt vector 
IVR7-0,| (reads back as software wrote it) 
or [Ack w/ 











DD 
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Miscellaneous Interrupt Status Register (MISR) Register Address 1 0b 01110 
RCC | DPLL | pra | BRGO 
RxCL/U| /RxC |TxCL/U;) /TxC (RxRL/U) /RxR |TxRL/U| /TxR |DCDL/U] /DCD |CTSL/U| /CTS | Under | DSync L/U L/U 
LU | LU 
14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Field/Bit Description RW |Ref Chapter: Section 
Name /Context Status 


MISR15 RxCL/U Read | 1=one or more transition(s) enabled by SICR15-]R,W1Uj3: The /RxC and /TxC Pins 
14 has (have) occurred on the /RxC pin p..35) 


Write} 1=open the latches for /RxC and for this bit 


( 
/RxC 1=the (first such) enabled transition was a rising 
aa edge; O=it was a falling edge | 

1=the /RxC pin is low; O=it's high 
TxCL/U Read] 1=one or more transition(s) enabled by SICR13-/R,W1U 
man 12 has (nave) occurred on the /TxC pin a 
Write| 1=open the latches for /TxC and for this bit 

[TxC 


1=the (first such) enabled transition was a rising 






—_ 
a 


w 
= 
2 




















































(pp.33-34) 


















R,W1U]3: The /CTS Pin (pp.34-35) 












RxRL/U Read | 1=one or more transition(s) enabled by SICR11-}/R,W1U/3: The /RxREQ and /TxREQ 
10 has (have) occurred on the /RxREQ pin Pins (pp.35-36) 
Write|1=open the latches for /RxR and for this bit 
1=one or more transition(s) enabled by SICR9-8 
DCDL/U Read|1=one or more transition(s) enabled by SICR7-6 
has (have) occurred on the /DCD pin 
Write| 1=open the latches for /DCD and for this bit 
1=one or more transition(s) enabled by SICR5-4 
edge; O=it was a falling edge 
RCC Under 
L/U 
allowed 


RxRL/U=1 | 1=the (first such) enabled transition was a rising 
has (have) occurred on the /TxREQ pin 
/DCD DCDL/U=1 | 1=the (first such) enabled transition was a rising 
has (have) occurred on the /CTS pin 
CTSL/U=0] 1=the /CTS pin is low; Osit's high 
DPLLDSync 1=DPLL has lost sync 3: More About the DPLL 
L/U (pp.30-31); 
6: Miscellaneous Interrupt 
— 





edge; O=it was a falling edge 
1=the /TxC pin is low; O=it's high 
edge; O=it was a falling edge 
1=the /RxREQ pin is low; O=it's high 
TxRL/U Read 
Write| 1=open the latches for /TxR and for this bit 
MISR8 /TxR TxRL/U=1 | 1=the (first such) enabled transition was a rising 
edge; O=it was a falling edge 
1=the /TxREQ pin is low; O=it's high 
edge; O=it was a falling edge 
1=the /DCD pin is low; O=it's high 
CTSL/U Read 
| Write|1=open the latches for /CTS and for this bit 
ICTS CTSL/U=1|1=the (first such) enabled transition was a rising 
1=RCC FIFO has counted down past 0 R,W1U/4: DMA Support Features: 
(Receive frame/message longer than max The RCC FIFO (p.68) 
BRG1 WU 
BRGO L/U 


1=BRG1 has counted down to 0 R,W1U]3: Tx and Rx Clocking: 


1=BRGO has counted down to 0 R,W1U|The Baud Rate Generators 
00.25-27 


=|= = = =| = = = = = = = = 
Nid” ” w w ¢2) w ~ i¢) w~ wm i ¢) (dp) 
pole Bt me) ps) ps wv Bs) ps) pe) Bu Bs) a 
oO};— nN a on Oo) “J Oo pairs mart = ere aire 

oO = ine) w BS 
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Next Receive Address Register Lower (NRARL) Register Address 0 1 b 11110 


LS 16 bits of "next receive address" (see below) 


15 14 13 12 11 10 S) 8 7 6 5 4 3 2 1 0 
Next Receive Address Register Upper (NRARU) Register Address 0 1 b 11111 


MS 16 bits of "next recelve address" (see below) 


15 14 1 












3 4 
Bit(s) Field/Bit Description Ref Chapter: Section 
Name /Context Status 


1 0 

NRARU15-0 Pipelined | 32-bit address of next Rx DMA buffer RW |5: Pipelined Mode (pp.83-85) 

NRARL15-0 Array or| 32-bit address in Array or Linked List (used to 5: Array Mode (pp.85-93) 
Linked List| fetch address and count of next Rx DMA buffer) 5: Linked List Mode (pp.87- 


12 11 10 9 8 7 6 5 3 2 

















90 


Next Receive Byte Count Register (NRBCR) Register Address 0 1 b 11101 
15 14 13 1 0 


10 9 8 7 6 5 3 2 1 


2 1 4 
Bit(s) Fiela/Bit Description Ref Chapter: Section 
Name /Context Status 


NRBCR15-0| | Pipelined| length of next Rx DMA buffer, inbytes |. RW _[5: Pipelined Mode (pp.83-85 
Next Transmit Address Register Lower (NTARL) Register Address 0 0 b 11110 





LS 16 bits of “next transmit address" (see below) 


16 14 13 12 11 10 9 8 7 6 5 4 3 2 1 7° 
Next Transmit Address Register Upper (NTARU) Register Address 0 0 b 11111 


MS 16 bits of "next transmit address" (see below) 

























15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Bit(s) | Field/Bit Description Ref Chapter: Section 
Name /Context Status 
NTARU15-0 Pipelined | 32-bit address of next Tx DMA buffer RW {5: Pipelined Mode (pp.83-85) 
NTARL15-0 | Array or| 32-bit address in Array or Linked List (used to 5: Array Mode (pp.85-93) 
Linked List| fetch address and count of next Tx DMA buffer) 5: Linked List Mode (pp.87- 
90 
Next Transmit Byte Count Register (NTBCR) Register Address 00 b 11101 


15 14 13 1 


10 S) 






2 11 
Name /Context : Status 


NTBCR15-0| ——_—sd:.s~ Pipelined{number of bytes in next Tx DMA buffer 5: Pipelined Mode (pp.83-85 





8 7 6 5 4 3 2 1 0 
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Port Control Register (PCR) Register Address 1 0 b 00101 
















Name /Context Status 
PCR15-14 |P7Mode 00=PORT7 pin is an input; RW_ {3: The Port Pins (pp.36-37) 
01=drive PORT7 with TxComplete; 
10=drive PORT7 low; 11=drive PORT7 hi 
PCR13-12 |P6Mode 00=PORTE pin is a GP input; 3: The Port Pins (pp.36-37) 
3: The Time Slot Assigners 
PCR11-10 |P5Mode = 
— 


01=PORTE6 pin is /FSYNC input; 
10=drive PORTE low; 11=drive PORTE hi 
PCR7-6 P3Mode L 4 
PCR5-4 P2Mode a 
























h 


















h 
3: The Port Pins (pp.36-37) 






10=drive PORTS low; 11=drive PORTS hig 
00=PORT4 pin is an input; 
01=drive PORT4 with Tx TSA Gate; 
10=drive PORT4 low; 11=drive PORT4 high 
00=PORTS pin is an input; 
01=drive PORTS with Rx TSA Gate; 
10=drive PORTS low; 11=drive PORTS hig 
00=PORT2 pin is an input; 
10=drive PORT2 low; 11=drive PORT2 high 
00=PORT1 pin is a GP input; 
01=PORT1 is CLK1 input; 
10=drive PORT1 low; 11=drive PORT1 hic 
00=PORTO pin is a GP input; 
01=PORTO is CLKO input; 
10=drive PORTO low; 11=drive PORTO hig 







3: The Port Pins (pp.36-37) 
3: The Time Slot Assigners 
(pp.37-39) 


3: The Port Pins (pp.36-37) 


3: The Port Pins (pp.36-37) 
3: Tx and Rx Clocking: CTRO 
and CTR1 (p.25) 


























00=PORTS pin is an input; 
01=drive PORTS with /RxSYNC; 
i“ 
PCR1-0 POMode 
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Port Status Register (PSR) Register Address 1 0 b 00100 















15 14 13 12 11 10 9 8 7 6 5 

| Name /Context 

IPSR15  |P7LW/U |  __ |1stransition detected on PORT7 pin 

P7L/U=1 | 1=rising edge on PORT7; O=falling edge 
P7L/U=0!1=PORT7 was low last time P7L/U:=1; 

0=PORT7 was hig 

1=transition detected on PORTE pin 

/P6 P6L/U=1] 1=rising edge on PORT6; O=falling edge 
P6L/U=0| 1=PORTE6 was low last time P6L/U:=1; 


4 3 2 1 0 
RW |Ref Chapter: Section 
Status 
( ) 


R,W1U}3: The Port Pins (pp.36-37 
























1=transition detected on PORTS pin 


/P5 P5L/U=1 | 1=rising edge on PORTS; 0=falling edge 


HV os os 
= = = 
G Cc Cc 





{=transition detected on PORTS pin 


= 
C 










WD 
<= 
a 





= 
Cc 
c 


1=transition detected on PORT1 pin 


os 
$ 
(oa 


U0} 0 0/0 U 0} U0 U0 |U 0|U 010 U 
ON) OM 2) NIN NIM OID iW op) 
Dj | UU iD DD | | DD DD 
oj Nh | oi iN oo Ice) | =| = 
o|— NM] s 

0 

w 

Cc 


D 
s 
Cc 
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Receive Address Register Lower (RARL) Register Address 0 1 b 10110 


LS 16 bits of current Rx DMA buffer address 


15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Receive Address Register Upper (RARU) Register Address 0 1 b 10111 


15 14 13 12 11 10 9 8 7 6 5 
Name /Context 


4 
RW 
Status 
RARU15-0 32-bit current address in Rx DMA buffer RW |5: DMA Fundamentals: 
RARL15-0 Addresses and Byte Counts 










Ref Chapter: Section 







0.79 
Receive Byte Count Register (RBCR) Register Address 0 1 b 10101 


15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Name /Context Status 
RBCR15-0 number of byte locations left in Rx DMA buffer RW 15: DMA Fundamentals: 
0.79 


Receive Character Count Register (RCCR) Register Address 1 0 b 10110 


ending count of oldest recelved frame/message In RCC FIFO 


15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Bit(s) Field/Bit Description Ref Chapter: Section 
Name /Context Status 
RCCR15-0 RCCAvail| final RCC value of oldest received frame/ 4: DMA Support Features: 
(CCSR14)|message in the RCC FIFO The RCC FIFO (p.68) 
=] 













147 


Receive Command/Status Register (RCSR) Register Address 1 0 b 10010 





RCmd (WO) ShortF/ Idle | Break | Rx | CRCE| Abort! Rx Rx 
fitBe{ CVType Reved | /Abort|Bound| /FE | /PE | Over | Avail 
9 8 7 6 5 4 3 2 1 0 


15 14 1 


3 
Field/Bit Conditions Ref Chapter: Section 
Name /Context Status 
S ( ) 


ync|0000=no operation; 0001=Reserved WO _ |4: Commands (pp.70-74 
0010=Clear Receive CRC Generator 
0011=Enter Hunt Mode; 0100=Reserved 
0100=Select RICRHi=RTSA Data 
0101=Select RICRHi=RxFIFO Status 
0110=Select RICRHi=/INT Level 
0111=Select RICRHi=/RxREQ Level 


1xxx=Reserved 


Last RDR} 1=2nd-oldest byte in RxFIFO had RxBound, PE, 
read was|or RxOver when RDR was last read 
16 bits 
ee oe | 
RxOver when RDR was last read 


-9 |RxResidue H/SDLC | 000=frame ended at character boundary 
001-111=number of extra bits at end 
0p.48-49 


ShortF/ H/SDLC, | 1=received frame ended before Address/Control]R,W1U}4: Status Reporting: 
CVType or RO |Detailed Status in the RCSR 
(pp.62-64) 


CMR7-4| fields (see Note 1) 
ExitedHunt | = —_—si[{ 1= receiver has left Hunt mode R,W1U 
ldleRcved | — |1=15 or 16 ones received R,WiU 
= R,W1U 


1=Break received W141 
| H/SDLC|1=Abort received (global/real-time flag 
RxBound Nine Bit] 1=address character (see Note 2) R,W1C 
ACV] 1=2nd (or only) byte of word (see Note 2) or RO 
HDLC/| 1=Flag or Abort followed this character 
SDLC| (see Note 2 
CRCE/FE Sync} 1=CRC not correct (at this point; see Note 1 
eee [asm 1=framing error (Stop bit = zero/space; see 


Abort/PE QAbort| 1=parity error (see Note 2) 


Bit(s) 

















mt) 
QO 
” 
= 
a 
nD 


DU 

O 
4 

a. 














4: Status Reporting: 
Detailed Status in the RCSR 
(pp.62-64) 













4: HDLC/SDLC Mode: 
Frame Length Residuals 














ACV] 0=received Data word 
1553B) | 1=received Command/Status word (see Note 1 









Ext Sync, | 1=end of message (see Note 2) 


802.3} 1=emd of frame (see Note 2) 









RxOver 1=RxFIFO overflow (see Note 2) R,W1C 


RCSRO 1=RxFIFO is not empt | RO | 


Note 1: the |USC carries these bits through the RxFIFO with data characters; they may represent the status of the oldest 
character or two currently in the FIFO, or of the last one or two read from it, as described in the referenced Chapter/Section. 
Note 2: the IUSC carries these bits through the RxFIFO with data characters; they may represent the status of the oldest 
character or two currently in the FIFO, of the last one or two read from it, or may be a cumulative/latched bit, as described in 
the referenced Chapter/Section. 





m8) JD DD BS) Didi D DD DD DD Bs) 
O 9) 9) O OID|O OQ O O O 
” 2) oy) Y”) NiMNiM ” oP) 62) ” 
D BS) BY Be DiD|D DD me) BS) Be 


ae 
O 
ae 
~ 
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Receive Count Limit Register (RCLR) Register Address 1 0 b 10101 


starting value for Receive Character Counter 


15 14 13 12 11 10 9 8 7 6 5 
Name /Context 
RCLR15-0 | ft} starting value for RCC: O=disable RCC; 
FFFF=enable RCC, no set max frame/message 
length; else maximum allowed length 


4 3 2 1 0 
RW |Ref Chapter: Section 
Status 


RW _ |4: DMA Support Features: 
The Character Counters 
pp.65-68 






















Receive Data Register (RDR) Register Address 1 0 b 1x000 or 1 1 b xxxxx 
15 14 13 12 11 10 9 8 7 6 5 0 













3 2 1 
Ref Chapter: Section 


4: The Data Registers and 
the FIFOs (pp.74-76) 


4 
Status 


Bit(s) Field/Bit Conditions| Description 
Name /Context 


RDR15-8 16 bit bus|the "other" received character in a 16-bit read 
(may be the oldest or 2nd-oldest per "Select 
D15-8 First" or "Select D7-0 First" commands in 
RTCmd [(CCAR15-11 
a 















| sreceivedcharacter 
Receive DMA Interrupt Arm Register (RDIAR) Register Address 0 1b 01111 
EOA/ | EOB |HAbort| SAbort 
3 2 1 0 


15 14 13 1 









2 14 10 9 8 7 6 5 4 
Name /Context Status 
RDIAR3 EOA/EOL IA Array,| 1=arm interrupt on End of Array/End of List RW |6: DMA Interrupt Sources 
Linked List} (RMCR3 and IA Bits (p.122) 









i 
RDIAR2  |EOBIA | ==———sd 4 sarm interrupt on End of Buffer (RDMR2 
RDIAR1 HAbortIA | ~~ _|4=arm interrupt on Hardware Abort (RDMR1 
RDIARO  |SAbortiA | ——_|1=arm interrupt on Software Abort (RDMRO 





149 


Receive DMA Mode Register (RDMR) Register Address 0 1 b 00001 


RSB | Clear EOA/ 
4 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


15 1 


Name /Context Status 
scans una 00=Single Buffer; 01=Pipelined: 
10=Array; 11=:Linked List 


RSBinA/L Array or|O=store Receive Status Blocks in data buffers RW {5: Storing Receive Status 
Linked List| after frames/messages; Blocks (pp.92-93) 
, 1=store RSBs in Array/List entries: 
ClearCount Array or} 1=clear Byte Count fields in Array/List entries to} RW _ 1|5: Array Mode (pp.85-93) 
Linked List} zero after fetching them 5; Linked List Mode (pp.87- 
90 
RDMR11-10 00=increment addresses; 
01=decrement addresses; 10=fixed address D.96 


TermE 1=terminate buffer on RxBound RW 15: DMA Fundamentals: 
Buffer Termination (pp.80- 
81 


8/16 6-bit bus| 1=8 bit transfers; RW _ {|5: DMA Fundamentals: Data 
0=16 bit transfers Width, Byte Ordering (p..80 













BS) 
Le) 
= 
Be) 
— 
o 









16-bi = 
command after loading Next Address and Coun 
ee castes | 
a list entry, or it stopped while doing so 
a ert 
command; O=the channel is stopped 
1=the channel is fetching information from the (ea 
| Linked List} array or linked list, or it stopped while doing so 
Linked List] or list, signified by a zero Byte Count field 
| _-__|1=the channel has reached the end of a buffer_| ROC _ 
pin went low while it was doing a memory cycle 
command 





es wv Bs) aw Be) pe) Bs) 
oO O oO oO O O Oo 
= = = = = = = 
pe) wv DD J J Be) wv 
oO — eS o) N ree) co 
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Receive Interrupt Control Register (RICR) Register Address 1 0 b 10011 


"RTSA data" If last RCSR15-12 command 4-7 was 4 idle | Break/} Rx Abort 
“RxFIFO fill level" If last RCSR15-12 command 4-7 was 5 | Exited Revad|-Abor:| Bound Word IPE RxOver| TCOR 
“Rx Int Req level" If last RCSR15-12 command 4-7 was 6 |HuntiA A iA IA Status ‘A IA Sel 
"Rx DMA Reg level" If last RCSR15-12 command 4-7 was 7 
7 6 5 4 3 0 


2 1 









































"offset" (number of bits delay) at which to 
activate Rx in each frame 











RICR15-8 4: The Data Registers and 


the FIFOs (pp.74-76) 










15 14 13 12 11 10 9 8 
Bit(s) Field/Bit Conditions Ref Chapter: Section 
Name /Context Status 
written 
Reset, 


RICR15-9 |RTSASlot 4 written to| "slot number" (number of bytes from frame RW _ 1/3: Time Slot Assigners 
there, write 
since 4, 6, 


RCmd| sync) at which to activate Rx in each frame 
RICR15-13 |RTSAOffset 
w/RICR8=1 
or 7 written 


since 5-7 
written 
there, read, | 
or write 
w/RICR8=0 
4 written to 
RCmd 
since 5-7 
RICR12-9 {|RTSACount | 4 written to} OO00=disable Rx Time Slot Assigner 
RCmd}0001-1111=number of consecutive bytes/ 
since 5-7| octets/time slots to receive in each frame 
written 
there, write 
w/RICR8=1 
5 written to| the number of characters/bytes/octets 
RCmd, or} currently in the RxFIFO 
there 
6 written to 
RCmd 
since4, 5, 
or 7 written 
there 
7 written to 
RCmd 













RICR15-8 







6: Receive Data Interrupts 
(p.116) 


number of characters/bytes/octets in the 
RxFIFO, above which to request a Receive 
Data interrupt 
























RICR15-8 5: DMA Requests by the 
Receiver and Transmitter 


(pp.97-99) 


number of characters/bytes/octets in the 
RxFIFO, above which to request Receive DMA 
transfer 


1=arm interrupts on ExitedHunt (RCSR7) 6 
S 


1=arm interrupts on IdleRcved (RCSR6 
1 


=arm interrupts on Break/Abort (RCSRS5) 





since 4-6 
written 


there 
Lonel 
ool 
—_ 
ee 
asad 
eee 
a 
= 





ExitedHunt | ‘ Receive Status Interrupt 


ources and IA Bits 


IdleRcvedlA 
Break/Abort 


RxBound IA 
WordStatus 


| RW_| 

|1=arm interrupts on RxBound (RCSR4) | «#RW_| 

O="queued" status in RCSR reflects oldest 4: Status Reporting 
character in RxFIFO; 1=two oldest characters pp.60-64 

[1=arm interrupts on Abort/PE (RCSR2)_—s |. «sRW_| 


1=arm interrupts on RxOver (RCSR1) 


O=select Time Constant value for reading TCOR} RW _ |3: Tx and Rx Clocking: The 
1=capture current count for reading TCOR Baud Rate Generators 
0p.25-27 


Abort/PE IA 
RxOver IA 





TCOR Sel 


al D[x] Dlx) DD] 2D | 
2) OO QO QO '@) 
me) | DID DD DD 
oO —/jPM Wh 01/0) aN 
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Receive Mode Register (RMR) Register Address 1 0 b 10001 


RxCRC RxPar 
2 1 0 


15 14 13 12 11 10 9 8 7 6 5 4 3 
101=decode RxD Biphase-Space (FMO); 
pane | 6 iblaveae| 00=Receive Parity Even; 01=Odd; 


Name /Context Status 
110=decode RxD Biphase-Level (Manchester); 
ion RxParEnab aioe OE: 1=accumulate & check Parity bits 



























000=RxD not encoded ("NRZ"); RW |3: Data Formats and 
111=decode RxD Differential Biphase-Level 


001=invert polarity of RxD ("NRZB"); Encoding (pp.29-30) 
010=decode RxD NRZI-Mark; 

011=decode RxD NRZ!I-Space; 
RMR12-11 |RxCRCType Sync|00=use 16-bit CRC-CCITT for Rx; 

01=use CRC-16 for Rx; 

10=use 32-bit Ethernet CRC for Rx 
ee ee O=start Receive CRC generator as all-zeroes; 
1=all ones 
nell RxCRCEnab| —_—sSync|1=include Receive characters in CRC 


100=decode RxD Biphase-Mark (FM1); 
RMR8 QAbort HDLC/| 1=use Abort/PE bit in RxFIFO, RCSR2 for Abort 
SDLC}] indication; O=use it for Parity Error indication 





4: Cyclic Redundancy 
Checking (pp.58-59) 












4: Status Reporting: Detailed 
Status in RCSR (pp.62-64); 
4: HDLC/SDLC: Handling a 
Received Abort (p.57 
4: Parity Checking (pp.59-60) 






















eee qe | Pe 000=receive eight bit characters; 4: The Mode Registers: 
001-111=receive 1-7 bit characters Character Length (pp.45-46) 
RxEnable 00=disable Receiver (immediately); 
a — 01=disable Rx at end of message/frame/char; 
10=enable Rx unconditionally; 
11=auto-enable Rx per /DCD pi 
Receive Sync Register (RSR) Register Address 1 0 b 10100 


Receive Sync, SYN1, or 9th-16th bits of Ethernet address Recelve SYNO or 1st-8th bits of address 
15 14 13 12 11 10 3 8 7 6 5 4 3 2 1 0 


Name /Context Status 

Monosync| Receive Sync match character RW 

Bisync| second half of Receive sync match (SYN1) Modes (pp.50-51) 

802.3] match against last-received 8 bits of address 4: ee oe Mode 
4: Monosync and Bisync 
Modes (pp.50-51) 
4: HDLC/SDLC Mode 
(pp.54-56) 


4: 802.3 (Ethernet) Mode 
Dp.53-54 
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Set DMA Interrupt Register (SDIR) Register Address 0 x b 01110 


Reserved (0) cs rae Reserved (0) DMs le 


15 14 13 1 10 9 8 7 6 5 4 3 2 1 0 


2 1 
Bit(s) Field/Bit Conditions| Description Ref Chapter: Section 
Name /Context Status 


SDIRQ RxDMA IUS read| 1=Rx DMA interrupt under service | RO |6: DMA IP and IUS Bits 
write| 1=set Rx DMA IUS bit; O=no change 
















(p.122) 

ele Keni eee cee ee 
write} 1=set Tx DMA IUS bit; O=no change | WO | 

SDIR1 |RxDMA IP read|1=Rx DMA interrupt pending 

oe 1=set Rx DMA IP bit; O=no change 

aoe xisticeet DMA w bie Dene shenps TW 
write| 1=set Tx DMA IP bit; O=no change 

Status Interrupt Control Register (SICR) Register Address 1 0b 01111 


TxCDn | TxCUp | RxRDn| RxRUp| TxRDn | TxRUp |DCDDn|DCDUp| CTSDn|cTsup| FES | PPLL | Bai | Broo 
IA IA IA IA IA IA IA IA IA IA std ae IA IA 
15 14 13 12 11 10 9 8 7 6 5 4 2 1 0 


3 


Bit(s) Field/Bit Description Ref Chapter: Section 
Name /Context Status 


SICR15 —-|RxCDnIA | =set MISR15/interrupt on fall of /RxC RW. |3: The /RxC and /TxC Pins 
SICR14 =set MISR15/interrupt on rise of /RxC 
SICR13 set MISR13/interrupt on fall of /TxC 
SICR12 set MISR13/interrupt on rise of /TxC 
ICR11 et MISR11/interrupt on fall of /RxREQ 
SICR10 RxRUp IA et MISR11/interrupt on rise of /RxREQ 


eee 
eek 
le acarit cas 
bee sal 
aa 
Ieee ae 
ICR9 TxRDnIA |  ——sd 4=set MISRQ9/interrupt on fall of TxREQ 
bose 
feet ec 
ae 
fee ae 
ieee 


= 


= 
O 


= 




















—s 













— | a 
uN 








—_ 





—- 


Wy yu 
i?) 


o 


3: /RxREQ and /TXREQ Pins 
(pp.35-36) 


3: The /DCD Pin (pp.33-34) | . 


3: The /CTS Pin (pp.34-35) 





—_— | 





= 
ICR8 set MISRQ/interrupt on rise of /TxREQ 
ICR7 set MISR7/interrupt on fall of /DCD 

SICR6 set MISR7/interrupt on rise of /DCD 

SICR5 set MISR5/interrupt on fall of /CTS 


SICR4 CTSUp IA =set MISR5/interrupt on rise of /CTS 


1=interrupt on RCC underflow 4: DMA Support Features: 

IA (Receive frame/message longer than max The RCC FIFO (p.68) 
allowed 

DPLLDSync {=interrupt on DPLL sync loss 3: More About the DPLL 

IA 


(pp.30-31); 
ICR1 BRG1 1A 1=interrupt on BRG1 zero 3: Tx and Rx Clocking: 


6: Miscellaneous Int. Source 
BRGO IA aa 1=interrupt on BRGO zero The Baud Rate Generators 
Dp.25-27 


—_ 
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i) 
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Test Mode Control Register (TMCR) Register Address 1 0 b 00111 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 








Bit(s) 


Fiela/Bit Description RW |Ref Chapter: Section 
Name /Context Status 


TMCR4-0 address of test register to read and write in 2?  |USC Family Test Modes 
TMDR (forthcoming separate 
document 
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Test Mode Data Register (TMDR) Register Address 1 0 b 00110 


Test Register selected by TMCR4-0 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Name /Context Status 


TMCR15-0 test register selected by TMCR4-0 varies | USC Family Test Modes 
| (forthcoming separate 
| document 


Time Constant 0 Register (TCOR) Register Address 1 0 b 10111 


divisor for (or current count in) Baud Rate Generator 0 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 « © 
Name /Context Status 


RW /|4: DMA Support Features: 
The Character Counters 


(pp.65-68) 











Time Constant 1 Register (TC1R) Register Address 10 b 11111 


divisor for (or current count In) Baud Rate Generator 1 
15 14 13 12 11 10° 9 8 7 6 5 4 3 2 1 0 
Name /Context Status 


write, or| divisor/starting value for BRG1: RW _ |4: DMA Support Features: 
read w/|O=input=output; 1=divide by 2; The Character Counters 


TC1RSel| n=divide by n+1 (pp.65-68) 
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Transmit Address Register Lower (TARL) Register Address 0 0 b 10110 


LS 16 bits of current Tx DMA buffer address 
12 11 10 9 8 7 6 5 4 3 2 1 0 


15 14 13 
Transmit Address Register Upper (TARU) Register Address 0 0 b 10111 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


Name /Context | Status 
TARU15-0 32-bit current address in Tx DMA buffer RW |5: DMA Fundamentals: 
TARL15-0 Addresses and Byte Counts 
D.79 
Transmit Byte Count Register (TBCR) Register Address 0 0 b 10101 


number of bytes left to send In current Tx DMA buffer 
8 7 


15 14 13 12 "a 10 9 6 5 4 3 2 1 0 
Name /Context Status 


TBCR15-0 number of bytes left to send in Tx DMA buffer RW {5: DMA Fundamentals: 
Addresses and Byte Counts 
0.79 

















Transmit Character Count Register (TCCR) Register Address 1 0 b 11110 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


Name /Context Status 





TCCR15-0 0=TCC disabled; else number of bytes (left) to 4: DMA Support Features: 
send in current/next Transmit frame/message The Character Counters 
0p.65-68 
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Transmit Command/Status Register (TCSR) Register Address 1 0 b 11010 


Txidle Pre idie | Abort ane TX Tx 
Sent | Sent | Sent S Under | Empty 
ent 
6 5 3 2 1 0 






















15 14 13 12 1 10 9 8 7 4 
Name /Context Status 
0000=no operation; 0001 =reserved WO. |4: Commands (pp. 70-74) 










Sync|0010=Clear Tx CRC Generator 

0011=reserved 

0100=Select TICRHi=TTSA Data 

0101=Select TICRHi=TxFIFO Status 

0110=Select TICRHi=/INT Level 

0111=Select TICRHi=/TxXREQ Level 

TICR2=1}1000=Send Frame/Message 
H/SDLC}1001=Send Abort 

101x=reserved 

T.Bisync|1100=Enable DLE Insertion 
1101=Disable DLE Insertion 
1110=Clear EOF/EOM 

1111=Set EOF/EOM 

selects the Transmit idle line condition: 

000=the default for TxMode (sync/Flag/Mark) 

001=alternating zeroes and ones 

010=continuous zeroes 

011=continuous ones 

100=reserved 

101=alternating Mark and Space 

110=continuous Space (TxD low) 

111=continuous Mark 


TCSR15-12 |TOmd 


TCSR10-8 |Txidle 








RW j{4: Between Messages, 
Frames, or Characters 
(pp.76-78) 














TxD high 

TCSR7 IPreSent | —__‘ Sync|1=Transmitter has finished sending Preamble _|R,W1U]4: Status Reporting: 
TCSR6 IdleSent | |1=Transmitter has sent Idle condition R,W1U] Detailed Status in the TCSR 
TCSR5 AbortSent H/SDLC|1=Transmitter has sent Abort R,W1U}(p.62) 
TCSR4 EOF/EOM 1=Transmitter has sent End of Frame/End of = |R,W1U 

Sent Message 
TCSR3 CRCSent 1=Transmitter has sent a CRC code R,W1U 
TCSR2 AllSent 1=last bit has gone out onto TxD | RO | 

TxUnder | ——_|{1=Transmitter has Underflowed R,W1U 

TxEmpty [| | 1=TxFIFO is empt | RO_| 
Transmit Count Limit Register (TCLR) ; Register Address 1 0 b 11101 

15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 






Name /Context Status 
TCLR15-0 starting value for TCC: O=disable TCC; RW 1/4: DMA Support Features: 
else length of next frame/message The Character Counters 
pp.65-68 
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Transmit Data Register (TDR) Register Address 1 0 b 1x000 or 1 1 b xxxxx 


Transmit character: write only using 16-bit operation Transmit character: 8- or 16-bit write 














15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Field/Bit Description RW |Ref Chapter: Section 
Name /Context Status 
TDR15-8 16 bit bus/the “other” Transmit character in a 16-bit write WO |4: The Data Registers and 
(may be sent 1st or 2nd per "Select D15-8 First" the FIFOs (pp.74-76) 
or "Select D7-0 First" command in RTCmd 
TDR7-0 |  & #&2X|  |Transmit character 
Transmit DMA Interrupt Arm Register (TDIAR) Register Address 0 0 b 01111 
EOA/ | EOB |HAbort} SAbort 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 


See the description of the Receive DMA Interrupt Arm Register (RDIAR). This one is Identical except that it arms 
status bits In the TDMR rather than the RDMR. 


Transmit DMA Mode Register (TDMR) Register Address 0 0 b 00001 


DMAMode | CB | Clear | pgarmode | terme! 8/16 | CONT] GLink| Busy | InITG | ECA! HAbort| SAbort 
InA/L | Count EOL 
4 13 12 11 10 9g 8 7 6 5 4 3 2 1 0 


15 1 


Name /Context Status 
10=Array; 11=:Linked List 


TDMR13 =| TCBinA/L Array or}O=fetch Transmit Control Blocks from data RW |5: Fetching Transmit Control 
Linked List| buffers before start of frames/messages; Blocks (pp.90-92) 
1=fetch TCBs from Array/List entries; 
TDMR12 ClearCount Array or|1=clear Byte Count fields in Array/List entries to] RW _ |5: Array Mode (pp.85-93) 
Linked List} zero after fetching them 5: Linked List Mode (pp.87- 
90 
TDMR11-10|AddrMode OO=increment addresses; ee Address Sequencing 























01=decrement addresses; 10=fixed address 
1=terminate buffer on RxBound RW |5: OMA Fundamentals: 
81 
0=16 bit transfers Width, Byte Ordering (p..80 
command after loading Next Address and Count . 






a list entry, or it stopped while doing so 
oe ee 1=the channel is operating per a Start ae 
command; O=the channel is stopped 
1=the channel is fetching information from the haa 
Linked List] array or linked list, or it stopped while doing 
EOA/EOL 1=the channel has reached the end of the array| RO 
Linked List} or list, as signified by a zero Byte Count field 
TTOMR2 |EOB | | 1=the channel has reached the end of a buffer 
HAbort Ld {=the channel stopped because the /ABORT | RO 
pin went low while it was doing a memory cycle 
aa Seale 1=software stopped the channel via an Abort | ROC 


command 





O 


OO 
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Transmit Interrupt Control Register (TICR) Register Address 1 0 b 11011 


"TTSA data" If last TCSR15-12 command 4-7 was 4 Idle | Abort 
"TXFIFO fill level" If last TCSR15-12 command 4-7was5 | Pre | oo | ‘colt 
"Tx Int Req level" If last TCSR15-12 command 4-7 was 6 |SentlA) © 

7 6 









"Tx DMA Reg level" if last TCSR15-12 command 4-7 was 7 i 
15 14 13 12 11 10 9 8 


Name /Context 

TTSASlot 4 written to}"slot number" (number of bytes from frame 
TCmdjsync) at which to activate Tx in each frame 

since 5-7 


written 
there, read, 


Bit(s) 











a 
QO 
= 
on 
co 






4 
O 
= 
¢ 
& 


4 written to 
TCmd 
since 5-7 
written 
there, write 
w/TICR8=1 
4 written to 
TCmd 
since 5-7 
written 
there, write 
w/TICR8=1 
5 written to 
TCmd, or 
Reset, 
since 4, 6, 
or 7 written 
there 
6 written to|the number of empty character/byte/octet 6: Transmit Data Interrupts 
TCmd/| entries in the TxFIFO, above which to request a (pp.118-119) 
since 4, 5,| Transmit Data interrupt 
or 7 written 
there 
7 written to}the number of empty character/byte/octet 
TCmd| entries in the TxFIFO, above which to request 
since 4-6! Transmit DMA transfer 
written 


reSent IA 1=arm interrupts on Preamble Sent (TCSR7 
IdleSentiA | —_—si{ 1=arm interrupts on IdleSent (TCSR6 
AbortSentiA | _H/SDLC]1=arm interrupts on AbortSent (TCSR5 


EOF/EOM 1=arm interrupts on EOF/EOM Sent (TCSR4) 
Sent lA 


there 
Syn 
3 
CRCSent IA 1=arm interrupts on CRCSent (TCSR3 
S = W 


Wait2Send ync|1=hold Transmitter from sending each R 4: Synchronizing Frames/ 
frame/message until software issues "Send Messages with Software 
Message/Frame" command Response (p.78 
TxUnder IA J=arm interrupts on TxUnder (TCSR1) RW 1/6: Transmit Status Interrupt 
Sources and IA Bits (pp.116- 
118 


TC1R Sel O=select Time Constant value for reading TC1R]} RW _ |3: Tx and Rx Clocking: 
1=capture current count for reading TC1R The Baud Rate Generators 
pp.25-27 



















"offset" (number of bits delay) at which to 
activate Tx in each frame 















a 
O 
zr 
© 
© 


TTSACount 0000=disable Tx Time Slot Assigner; 
0001-1111=number of consecutive bytes/ 


octets/time slots to send in each frame 
















the number of character/byte/octet entries 
currently empty in the TxFIFO 


4: The Data Registers 
and the FIFOs (pp.74-76) 













a 
O 
a 
i 
co 



















a 
© 
= 
on 
oo 


5: DMA Requests by the 
Receiver and Transmitter 
(pp.97-99) 






ICR7 
ICR6 


6: Transmit Status Interrupt 
Sources and IA Bits 
(pp.116-118) 
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Transmit Mode Register (TMR) Register Address 1 0 b 11001 
TxCRC | TxCRC | TxCRC TxPar 
15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 
Name /Context Status 


TMR15-13 |TxEncode 000=don't encode TxD ("NRZ"); RW {3: Data Formats and 
001=invert polarity of TxD ("NRZB"); Encoding (pp.29-30) 
010=encode TxD NRZI-Mark; 
011=encode TxD NRZI-Space; 
100=encode TxD Biphase-Mark (FM1); 
101=encode TxD Biphase-Space (FMO); 
110=encode TxD Biphase-Level (Manchester); 
111=encode TxD Differential Bipnase-Level 


4: Cyclic Redundancy 
Checking (pp.58-59) 










TMR12-11 |TxCRCType Sync|O00=use 16-bit CRC-CCITT for Tx; 
01=use CRC-16 for Tx; 
10=use 32-bit Ethernet CRC for Tx 
1=all ones 


ITMRQ sd TxCRCEnab 1=include Transmit characters in CRC 
TMR8 TxCRCatEnd —_— Sync|1=send accumulated CRC at EOF/EOM 


TMR9Q 
TMR8 
TMR7-6 TxParType 00=Transmit Parity Even; 01=Odd; 4: Parity Checking (pp.59-60) 





TMRS5 TxParEnab 1=accumulate & send Parity bits 


deat ity bi 
TMR4-2. ‘| TxLength ae 000=send eight bit characters; 4: The Mode Registers: 
001-111=send 1-7 bit characters Character Length (pp.45-46 


TMR1-0 TxEnable 00=disable Transmitter (immediately); 4: Tne Mode Registers: 


01=disable Tx at end of message/frame/char; Enabling and Disabling 
Transmit Sync Register (TSR) Register Address 1 0 b 11100 










10=enable Tx unconditionally; (p.45) 
per /CTS 






11=auto-enable Tx pin 


Transmit SYN1 Transmit Sync or SYNO 















15 4 3 2 1 0 

Bit(s) Field/Bit Conditions Ref Chapter: Section 
Name /Context Status 

RSR15-8 4: Monosync and Bisync 










Monosync, | Transmit Sync character Modes (pp.50-51) 


4: Slaved Monosync Mode 


14 13 12 11 10 9 8 7 6 5 
(p.53) 


| =| Bisyne| second half of Transmit sync (SYN1 
Z i 





Bisync| first half of Transmit sync (SYNO 
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Appendix: Changes 


This section summarizes the changes in the names of 
registers and commands since the original USC 
Technical Manual, as well as the improvements added 
in the 16C32. 


Transmit Status Blocks-->Transmit Control Blocks 


The names of registers and other USC features, in 
past documentation, maintained the distinction 
between "status" info as flowing from the USC to the 
host, and "control" information as flowing from the 
host to the USC pretty strictly -- all except this one. 


Interrupt Enable (for individual sources) --> 
Interrupt Arm 


There was no distinction between the enabling of a 
whole interrupt type and the enabling of an individual 
source within a type, and it seemed important to 
distinguish between these, so we kept the former as 
"enabling" and called the latter "arming" instead. 
Vague memories of early minicomputer terminology 
say the same terms were used. 


Commands 


Reload RCC / TCC --> Load RCC/TCC 


It wasn't clear why RCC and TCC were "reloaded" 
while TCO and TC1 were just "loaded". 


Select Straight/Swapped Memory Data --> Select 
D15-8/D7-0 First 


"Straight" means whichever way your microprocessor 
wants it, while "swapped' is the way the other guys’ 
part works... 


Preset CRC --> Clear Tx/Rx CRC Generator 


More descriptive of the function: "preset" seemed to 
carry the possibility that you might be able to load in 
any arbitrary starting value... 


Bit/Field Names 


There weren't really bit and field names in the old 
Technical Manual -- they were more like text titles. But 
for those bits and fields that had fairly short titles, the 
names in this manual may or may not be the same. 
One change of note is that RCSR4 has been changed 
from "CV/EOF/EOM" to "RxBouna", after it was noted 
that the bit has a fourth use: in Nine-Bit mode it flags 
address bytes. ("CV/EOF/EOM/Addr" seemed a little 
long...) 


Another such change is that CCSR14 is now called 
RCCF Avail rather than RCC Valid. (it's perfectly 
valid for the RCC FIFO to be empty, in which case 
there's nothing available to be read from it.) 
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The bit and field names in this book are similar to, but 
not identical with, those in the Electronic Program- 
mer's Manual. 


Changes from the 16C31 


Here's what's new in the 16C32, including the page 
number of "the most important" description of each: 


1. The redundant ByteSwap field in the BCR was 
removed in favor of using the state controlled by 
the "Select D15-8 First" and "Select D7-0 First 
commands. (p.14) 


The PORTO/CLKO and PORT1/ CLK1 pins can 
now carry direct bit clocks, without dividing them 
in CTRO and CTR1. (p.25) 
A hardware or software Reset forces the PORT 
pins to input status. (p.36) 


HDLC/SDLC Abort status can be queued with 
received characters (p.64) 


Receive Data interrupts are delayed by one 
receive bit clock so that the RCC FIFO status is 
correct at the time of such an interrupt. (p.68) 


Improved synchronization and __ interlocking 
between the serial clock and bus transactions 
have eliminated incorrect FIFO status and 
Receive DMA requesting. (pp.75-76) 


Flags can be used as a Preamble, for remote 
equipment that needs more than one or two of 
them, or for slowing down the frame rate slightly 
for congestion management. (p.77) 


A DMA channel operating in 16-bit mode will do a 
byte transfer if a buffer starts at an odd address, 
or if the last character of a frame doesn't 
complete a 16-bit word. (p.80) 


In array and linked list modes, the DMA channels 
can clear the Byte Count of each buffer after 
fetching it, to prevent ring wraparound when a 
linked list is arranged as a ring of buffers. (pp. 
89-90) 

In array and linked list modes, the DMA channels 
can fetch Transmit Control Blocks and store 
Receive Status Blocks in the array/list entries 
rather than with the data. On the receive side this 
eliminates the need for interrupt service routines 
to read the RCC FIFO as frames arrive, for frame 
length determination. (pp.90-93) 


The DMA channels’ state variables had to be 
expanded to implement 9 and 10. (pp.104-105) 


10. 


Vhs 


Index 


In the following index: 






Bold page numbers identify the definition or main 
explanation of a term. 






Italic page numbers identify a Figure that illustrates the 
term. 









Bold Italic page numbers identify a section about the 
term, that includes both text and pictorial information. 





/ABORT pin, 7, 80, 83, 94, 102-103, 104, 122 


/AS pin, 6, 11, 16, 27-24, 100, 101, 102-103, 110, 
117-114, 115 


/BIN pin, 7, 97, 100, 101, 702-103, 104 

/BOUT pin, 7, 100 

/BUSREQ pin, 7, 14, 95, 97, 100, 104, 128, 137 

/CS pin, 5, 11, 14, 21-24 

/CTS bit, 35, 143 

/CTS pin, 8, 32, 34-35, 45, 53, 119 

/DCD bit, 34, 143 

/DCD pin, 8, 32, 33-34, 45, 50, 53, 54, 63, 64, 67, 115, 
119 

/DS pin, 6, 12-13, 14, 27-24, 100, 102-103, 104, 110, 
111-114, 115 

/DTACK, see /WAIT//RDY pin 

/FSYNC, 36, 37-38 

ANT pin, 7, 15, 52, 54, 55, 60, 72, 107, 108, 110, 777- 
1714, 119, 120, 128 

/JINTACK pin, 7, 12, 14, 21-24, 107, 108, 110, 177- 
1714, 115, 128 


[IRQTP, 15, 110, 128 
/P7-0 bits, 36, 146 


/RD pin, 6, 12-13, 14, 21-24, 100, 102-103, 104, 110, 
111-174, 115 


/RESET pin, 5, 11, 33, 74, 75 

/RxACK, 35, 36 

/RxC bit, 35, 143 

/RxC pin, 7, 25, 27, 28, 32, 34, 35, 37-38, 50, 119 
/RxD pin, 34, 37-38 

/RxR bit, 36, 143 

/RxREQ pin, 7, 32, 35-36, 52, 54, 55, 68, 73, 78, 119 
/RxSYNC, 36 

[TxACK, 35, 36 

/TxC bit, 35, 143 

/TxC pin, 7, 25, 27, 28, 32, 34, 35, 37-38, 53, 119 
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/TxD pin, 34, 37-38 

/TxR bit, 36, 143 

/TxREQ pin, 7, 32, 35-36, 67, 68, 72, 73, 99, 119 
/UAS Frequency, 23, 101 

/UAS pin, 6, 23, 100, 101, 102-103, 104 


IWAIT//RDY pin, 5, 6, 13, 14, 21-24, 96, 101, 102-103, 
104, 171-1174, 115, 121, 123, 125 


IWR pin, 6, 12-13, 14, 27-24, 100, 102-103, 104 


1553B, 33, 46, 48-50, 49, 63, 64, 65, 69, 70, 72, 75, 
81, 99, 115, 132 


16Bit, 14, 80, 85, 97, 98, 105, 128 
16COx, 72, 75 

1stBE, 63, 70, 148 

1Wait, 101, 138 


2ndBE, 62, 148 
680x0, 72, 75, 79 


8/16, 80, 85, 98, 105, 150, 157 


802.3, 33, 53-54, 58, 63, 64, 67, 68, 69, 70, 77, 81, 
99, 115, 133 


80x86, 75, 79 


A15 (carry out of), 101, 104 
Abort 
All Channels (command), 80, 94, 96, 122 
Handling a Received, 57 
Hardware, see /ABORT pin 
Master Cycle, see /ABORT pin 
Sequence (HDLC/SDLC), 44, 55, 56, 60, 62, 63, 
64, 73, 115, 116, 148 
This Channel (command), 80, 94, 96, 122 
Abort/PE, 57, 60, 61, 64, 70, 116, 148 
Abort/PE IA, 64, 115, 151 
AbortSent, 62, 156 
AbortSent IA, 62, 118, 158 
Acknowledge, see /WAIT//RDY pin | 
AD pins, 5, 11, 21-24, 72, 73, 80, 97, 100, 102-103, 
111-114, 115, 128 
Adding a Buffer to a List, 90 


Address, 63 
/Data Bit, 48 
/Data Bus, see AD pins 
All Ones, 54, 55 
Buffer, 79, 85, 87 
Character, 115 
Destination, 54 
DMA, 81 
Even, 66, 72, 75 
Extended (HDLC/SDLC), 56 
Field Handling (HDLC/SDLC), 55, 63 
Implicit, 16 
Indirect, 16 
Link, 87 
Odd, 66, 73, 75 
Receive DMA, 81 
Register, 15-19, 74 
Separate, 14 
Sequencing, 96 
Source (Ethernet), 54 
Strobe, see /AS pin 
Upper, see /UAS pin 
Transmit DMA, 81 
Wakeup, see Nine-Bit 
AddrMode, 96, 150, 157 
AddrSeg, 96, 101, 138 
ALBVO, 97, 98, 138 
All Ones, 48, 58, 65, 68, 70, 71, 76 
Address, 54, 55 
All Zeroes, 71 
AllSent, 62, 156 
Alternating bits, 54 
Army, 48, 50 
Array 
/List Binary Value Order, 97 
/List vs. Serial Cycles, 5 
Fetch, 80, 104 
Mode, 9, 68, 70, 85-87, 94, 96, 97, 101, 122 
Array Mode, 90, 92, 104 
ASCII, 52 
Async with Code Violations, see 1553B . 
Asynchronous, 25, 28, 32, 33, 34, 41-42, 46-47, 59, 
63, 64, 72, 76, 77, 115, 132 
Auto-enabling, 53 


B//W, 6, 15, 129, 137 
Backoff, 53 
Baud Rate Generators, see BRGO and BRG1 
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BCR, 5, 6, 7, 8, 11, 13, 14-15, 74, 80, 85, 97, 101, 
105, 110, 111, 112, 125, 128 
BDCR, 90, 97, 104, 128 
Between Frames, Messages, or Characters, 76-78 
Big Endian, 20, 66, 79, 80, 92, 138 
Binary Format (in Arrays/Lists), 97 
Binary Synchronous Communications, see Bisync 
Biphase, 119 
Biphase-Level, 29, 30, 31, 48, 53 
Biphase-Mark, 29, 30, 31, 48 
Biphase-Space, 29, 30, 31 
Bisync, 33, 50-53, 58, 63, 132 
Transparent, see Transparent Bisync 
Block Diagram, 9 
Break, 32 
Break/Abort, 47, 57, 60, 63, 116, 148 
Break/Abort IA, 63, 115, 151 
BRGO, 25-27, 35, 72 
BRGO IA, 27, 120, 153 
BRGOE, 27, 139 
BRGOL/U, 27, 143 
BRGOS, 139 
BRGOSre, 27, 28, 135 
BRG1, 25-27, 35, 72 
BRG1 IA, 27, 120, 153 
BRG1E, 27, 139 
BRGI1L/U, 27, 143 
BRG1S, 27, 139 
BRG1Src, 27, 28, 135 
BRQTP, 14, 97, 128 
Buffer 
Address(es), 79, 85, 87 
Ring, 89 
Termination, 80-81 
Termination, Early, 80, 97 
Burst/Dwell Control Register, see BDCR 
Bus 
Acknowledge In, see /BIN pin 
Acknowledge Out, see /BOUT pin 
Acquisition, 100-101 
Address/Data, see AD pins 
Configuration Register, see BCR 
Cycles 
Interrupt Acknowledge, 111-114 
Master, 6, 107-103 
Register Access, 21-24 
Data, see AD pins 


Bus (continued) 
Interfacing, 11-24 
Multiplexed, 11, 15, 27-22, 102-103, 111 
Non-multiplexed, 11, 14, 23-24, 112 
Occupancy Throttling, 104 
Release, 100-101 
Request, see /BUSREQ pin 
Totem Pole (vs. open drain), 14 
Serial, 31, 32 
Width, 13, 14, 80 
BUSY, 83, 90, 94, 96, 97, 99, 150, 157 
Byte Count, 79, 80, 85, 87, 90, 92 
Receive, 81 
Transmit, 81 
Zero, 79, 87, 89, 90, 94 
Byte Ordering, 20, 80 
Byte/Word Select, see B//W 
ByteSwap, 14 


C//D pin, 11 
Carrier Detect, see /DCD pin 
CCAR, 11, 14, 15, 16, 20, 27, 32, 50, 54, 56, 64, 65, 
68, 71, 74, 75, 78, 79, 80, 99, 120, 126, 129 
CCR, 28, 46, 51, 53, 55, 62, 65, 68, 69, 70, 72, 74, 77, 
78, 79, 92, 93, 99, 118, 137 
CCSR, 25, 30, 37, 53, 56, 57, 58, 68, 69, 78, 130 
CDIR, 122, 134 
ChanLoad, 126, 129 
Channel 
Command/Address Register, see CCAR 
Command/Status Register, see CCSR 
Control Register, see CCR 
Mode Register, see CMR 
Select (DMA), 5, 95 
ChanPri, 99, 138 
Character 
Clocks, 35 
Counters, see RCC and TCC 
Length, 45-46 
Pairs, 51 
Partial, 56 
Chip Select, see /CS pin 
Clear 
DMA Interrupt Register, see CDIR 
EOF/EOM (command), 71 
RCCF, 68, 130 
Rx CRC (commana), 58, 71 
to Send, see /CTS pin 
Tx CRC (command), 58, 71 
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ClearCount, 85, 87, 89, 90, 105, 150, 157 
CLK, 5, 100, 101, 102-103, 104 
Max per Bus Grant, 128 
CLK1-0 pins, 25 
Clock(s), 25-29 
External, 25, 47 
from PORT pins, 8, 25 
Logic Model, 26 
Missing, 30, 53, 119 
Mode Control Register, see CMCR 
Receive, see RxCLK, /RxC pin 
Reference, 36 
Stopping, 28-29 
Synchronous, 28 
Transitions, 31 
Transmit, see TxCLK, /TxC pin 


Closing Flag, 55, 58, 73, 76 
Closing Sync, 76 

CMCR, 25, 26, 27, 28, 135 
CMOS, 28 


CMR, 28, 33, 44, 46, 47, 48, 49, 50, 51, 52, 53, 54, 
55, 57, 59, 63, 69, 73, 76, 77, 132-134 

Code Violation, 31 

Collisions, 53 

Command(s), 51, 52, 70-71, 120, 160 
/Status Word, 48, 49, 50, 63, 70 
DMA, 95-96 

Conditions for DMA Operation, 97 

CONT, 83, 94, 96, 122, 150, 157 

Control Field 
Extended, 56 

Control Field Handling, 55, 63 

Counters, see CTRO and CTR 
Character, see RCC and TCC 

CRC, 42, 50, 51, 52, 53, 54, 56, 57, 58-59, 65, 66, 71, 

73, 76, 78 

CRCE/FE, 47, 59, 60, 61, 64, 70, 78, 148 

CRCSent, 62, 77, 156 

CRCSent IA, 62, 118, 158 

CTRO, 25,35,36 

CTRODiv, 25, 139 

CTROSre, 25, 28, 135 

CTR1, 25, 35, 36 

CTR1DSel, 25, 28, 139 

CTR1Sre, 25, 28, 135 

CtrBypass, 25, 130 

CTSDn IA, 35, 119, 153 


CTSL/U, 35, 143 
CTSMode, 34, 45, 53, 140 
CTSUp IA, 35, 119, 153 
CV/EOF/EOM, 160 
CVOK, 31, 139 
CVType, see ShortF/CVType 
Cycle(s), 13 
Interrupt Acknowledge, 110-115 
vs. Read, 115 
Master, 6, 101-103 
Max per Bus Grant, 128 
Read, 6 
Register Access, 21-24 
Slave, 6 
Write, 6 
Cyclic Redundancy Check(ing), see CRC 


D//C pin, 5, 16, 27-24, 74, 100, 101, 138 
DACR, 105, 137 
Daisy Chain(s), 7, 107 
Control Register, see DCCR 
Data 
/Control, see D//C pin 
Bus, see AD pins 
Carrier Detect, see /DCD pin 
Decoding, 29-30, 77 
Encoding, 29-30 
Formats, 29-30 
Interrupts, see Receive and Transmit Data 
Interrupts 
Receive, see RxD pin 
Registers, 74-75 
Strobe, see /DS pin 
Transitions, 31 
Transmit, see TxD pin 
vs. Address (Nine-Bit), 48 
Width, 13, 14, 80 
Word, 48, 49, 50, 63, 70 
DCAR, 11, 15, 16, 80, 81, 83, 87, 90, 93, 94, 95, 97, 
122, 137 
DCCR, 32, 110, 116, 119, 120, 127, 136 
DCDDn IA, 34, 119, 153 
DCDL/U, 34, 143 
DCDMode, 33, 45, 50, 54, 140 
DCDup IA, 34, 119, 153 
DCmd, 95, 122, 137 
DCR, 23, 96, 97, 99, 100, 101, 104, 138 
DCSDOut, 101, 138 


Decrement (DMA address), 96 
Destination Address, 48, 54 
DICR, 110, 123, 138 
Differential Biphase-Level, 29, 30, 31 
Digital Phase Locked Loop, see DPLL 
Disable DLE Insertion (command), 52, 72 
Disable Lower Chain, see DLC 
Disabling (Rx and Tx), 45 
DIVR, 123, 139 
DLC, 110, 120, 123, 138, 141 
DLE, 52, 64, 72 
DLE-SOH, 52 
DLE-STX, 52 
DLE-SYN, 52 
DMA, 8, 79-105 
Abort 
Hardware, 7, 94 
Software, 94, 96 
Address, 81 
Array Count Register, see DACR 
Byte Count, 81 
Channel Select, 5, 95 
Command/Address Register, see DCAR 
Control Register, see DCR 
Cycle(s), 6, 101-103 
Options, 22-23, 101 
Initializing a Serial Channel via, 126 
Interrupt Control Register, see DICR 
Interrupt Vector Register, see DIVR 
Interrupt(s), 81, 83, 87, 89, 127-123 
Request Level, 73, 75, 79, 97, 99 
Request(s), 7, 8, 52, 54, 55, 67, 68, 73, 78, 79, 
97-99 
Support Features, 64-70 
DMAMode, 79, 150, 157 
Double Pulse mode (of interrupts), 110, 114 


DPLL, 25, 27, 28, 30-31, 35, 47, 78, 119 


-DPLL1Miss, 31, 130 


DPLL2Miss, 31, 130 
DPLLDiv, 27, 139 
DPLLDSync IA, 119, 153 
DPLLDSync L/U, 31, 143 
DPLLEdge, 30, 31, 130 
DPLLMode, 30, 139 
DPLLSre, 27, 135 
DPLLSync, 31, 78, 130 
Driver (TxD), 8, 38, 53 
Dynamic Priority, 107 


Early Buffer Termination, 70, 80, 83, 87, 92, 94, 122 
EBCDIC, 52 
Echo, 32 
Edge Detection, 32, 119 
Electrical Specifications, 10 
Enable DLE Insertion (command), 52, 72 
Enabling (Rx and Tx), 45 
Encoding of Data, 29-30 
End Of 
Array, see EOA/EOL 
Buffer, see EOB 
Frame, 53, see also EOF/EOM and RxBound 
List, see EOA/EOL 


Message, 51, 53, see also EOF/EOM and 
RxBound 


ENQ, 52, 64 
Enter Hunt Mode (command), 68, 72 
EOA/EOL, 94, 122, 150, 157 
EOA/EOL IA, 149 
EOB, 94, 122, 150, 157 
EOB IA, 149 
EOF/EOM, 51, 53, 58, 66, 67, 71, 73 
Sent, 62, 77, 156 
Sent IA, 62, 118, 158 
EOT, 52, 64 
ETB, 52, 64 
Ethernet, see 802.3 
ETX, 52, 64 
Even Address, 66, 72, 75, 80 
ExitedHunt, 63, 78, 116, 148 
ExitedHunt IA, 63, 115, 151 
Experts, 10 
Extended Address (HDLC/SDLC), 56 
Extended Control Field, 56 
External 
Clocking, 25, 47 
Driver, 8, 38 
Hardware, 53 
Interrupt Control Logic, 107-108 
Sync, 33, 50, 58, 63, 64, 67, 68, 69, 132 
Extra CLK Periods (DMA), 104 


Falling Edges, 119 
FE, see CRCE/FE 
Features, 1 

Fetching TCB's, 90-92 


FIFO, see RxFIFO and TxFIFO 
Capacity, 75 
First Byte Exception, see 1stBE 
Fixed (DMA address), 96 
Flag(s), 29, 33, 43, 54, 56, 57, 58, 62, 63, 64, 65, 66, 
67, 72, 73, 115, 118 
Closing, 55, 58, 73, 76 
Idle, 58, 76 
Minimum Number of, 55, 77 
Opening, 55, 77 
Single, 77, 78 
FlagPreamble, 77, 131 
Flowchart 
Queued Status Bits, 67 
Register Addressing, 19 
Sample Receive Status Interrupt Service Routine, 
117 
Flyby, 74 
FMO, 30 
FM1, 30 
Format(s) 
Binary Values, 97 
Data, 29-30 
Fractional T1, 8, 37 
Frame(s), 53, 54, 55 
Length, 65, 68, 70 
Max Received, 67 
Residual, 56-57 
Sync, 8, 36, 37 
Delay, 38 
Framing Error, see CRCE/FE 


Gate 
Receive Time Slot Assigner, 8, 38 
Transmit Time Slot Assigner, 8, 38 
GLink, 94, 104, 105, 150, 157 
Global (address), 54 
Go Ahead, 44, 57, 63, 73 
Ground pins, 8 


HAbort, 94, 122, 150, 157 

HAbort IA, 149 

Handling 
Address Field (HDLC/SDLC), 55, 63 
Control Field, 55, 63 
Received Abort, 57 

Handshaking, 13 


Hardware . 
Abort, see /ABORT pin 
Configuration Register, see HCR 
External, 53 


HCR, 25, 26, 27, 30, 31, 139 
HDLC/SDLO, 29, 30, 33, 43, 46, 54-57, 58, 63, 64, 68, 
69, 70, 73, 77, 78, 81, 99, 115, 118, 133 
Loop, 57-58, 69, 76, 134 
Holding Between Frames, 78, 97, 99 
Hunt, 53, 63, 70, 72 


[/O Pin Interrupts, 119 
IA, 32, 60, 61, 108, 109, 110, 116, 118, 119, 120, 122, 
160 : 
|AckMode, 14, 110, 111, 112, 113, 114, 115, 128 
ICR, 27, 110, 120, 121, 141 
Idle, 48, 51, 53, 55, 57, 62, 73, 76, 77, 78 
Flag, 58, 76 
IdleReved, 60, 63, 78, 116, 148 
IdleReved IA, 63, 115, 151 
IdleSent, 62, 77, 156 
IdleSent IA, 62, 118, 158 
IE, 96, 108, 109, 120, 122, 160 
IE Op, 120, 141 
IEEE 802.3, see 802.3 
IEI pin, 7, 107, 108, 110, 111, 172, 173, 114, 119, 122 
IEO pin, 7, 107, 108, 110, 111, 172, 114, 120 
Implicit Addressing, 16 
Increment (DMA address), 96 
Indirect Addressing, 16 
INITG, 85, 87, 94, 96, 97, 104, 105, 150, 157 
Initializing via a DMA Channel, 74, 126 
Input/Output Control Register, see |OCR 
Inserted Zeroes, 55, 56 
Intel, 14, 15, 16, 20, 72, 75, 97, 114 
Inter-Channel Operation and Priority, 99 
Interlocks, 76 
Interrupt(s), 107-121 
Acknowledge, 14, see also /INTACK pin 
Cycle(s), 108, 110-115 
Daisy Chain, 7, 107 
vs. Read Cycles, 115 
Arm, see lA 
Control Register, see ICR 
DMA, 81, 83, 87, 89, 121-123 
Edge Detection, 32 
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Interrupt(s) (continued) 
Enable, 120, see a/so IE 
In, see IEI pin 
Out, see IEO pin 
\/O Pin, 32, 119 
Logic Model, 109 
Miscellaneous, 119-120 
Nested, 107, 110 
Options 
DMA, 123 
Serial, 120-121 
Receive Data, 116, see also RD IP 
Request Level, 116 
Receive Status, 115-116 
Request Level, 73, 75 
Receive, 116 
Transmit, 118 
Request(s), see also /INT pin 
Totem-Pole, 15 
Sources, 108 
DMA, 122 
Serial, 115-120 
Transmit Data, 118 
Request Level, 118 
Transmit Status, 116-118 
Types, 108 
DMA, 121 
Serial, 115-120 
Vector(s), 107, 110, 114, 121, 142 
DMA, 123 
Register, see IVR 
Serial, 121 
IOCR, 32, 33, 34, 35, 45, 47, 50, 53, 119, 140 
IOP IE, 120, 141 
IOP IP, 32, 119, 120, 136 
IOP IUS, 120, 136 
IP, 96, 108, 109, 110, 120, 122 
IP Op, 120, 136 
ISDN, 8, 37 
Isochronous, 33, 47, 64, 132 
ITB, 52, 64 
IUS, 7, 72, 96, 108, 109, 110, 111, 114, 120, 121, 122, 
123, 136 | 
IUS Op, 120, 136 
IVR, 121, 142 


L/U, 32, 119 
Latched/Unlatch, 32, 119 


Length 
Character, 45-46 
Field (Ethernet), 54 
Frame, 65, 68, 70 
Max Received, 67 
Residual, 56-57 
Message, 65 
Level 
DMA Request, 73, 75, 79, 97, 99 
Interrupt Request, 73, 75, 116, 118 
Receive Data Interrupt Request, 116 
Transmit Data Interrupt Request, 118 
Line Driver, 53 
Link Address, 87 
Linked List Fetch, 80, 104 
Linked List mode, 9, 68, 70, 87-90, 92, 94, 96, 97, 
101, 104, 105, 122 
Little Endian, 15, 20, 79, 80, 92, 138 
Load RCC (command), 65, 72 
Load TCO (command), 27, 72 
Load TC1 (commana), 27, 72 
Load TCC (command), 65, 68, 72 
Local Loop, 32 
Logic Model 
Clock(s), 26 
Interrupts, 709 
RCC, 67 
Receive Datapath, 59 
TCC, 66 
Logic Symbol, 7 
LoopSend, 58, 130 
Lower Register, 79 
LSB First, 73 


Manchester, 30 
Mark, 42, 53, 76 
Parity, 60 
Master 
Bus Cycles, 6, 101-103 
Bus Request Enable, see MBRE 
Interrupt Enable, see MIE 
MaxCLkKs, 90, 104, 128 
MaxxXfers, 90, 104, 128 
MBRE, 83, 90, 95, 97, 99, 137 
Message(s), 42, 51, 52, 53, see also Frame(s) and its 
subtopics 
MIE, 27, 109, 119, 120, 122, 123, 138, 141 
MinOff39, 97, 104, 138 


Miscellaneous Interrupt(s), 119-120 
Status Register, see MISR 

MisclE, 27, 120, 141 

MisclP, 119, 120, 136 

MisclUS, 120, 136 

MISR, 27, 33, 35, 36, 67, 119, 120, 143 

Missing Clock(s), 30, 48, 53, 119 

Model, see Logic Model 

Monosync, 33, 50-53, 58, 63, 132 
Slaved, 53, 58 

Motorola, 16, 20, 72, 75, 97 

MSB First, 73 


Nested Interrupts, 107, 110 
Newcomers, 10 


Next 
Receive Address Register, see NRAR 
Receive Byte Count Register, see NRBCR 
Transmit Address Register, see NTAR 
Transmit Byte Count Register, see NTBCR 


Nine-Bit, 33, 48, 64, 115, 133 
No Vector, see NV 
Non-Existent Memory, 104 
NRAR, 83, 85, 87, 89, 94, 144 
NRBCR, 83, 87, 94, 144 
NRZ, 25, 29, 30, 31, 45 
NRZB, 29, 30 

NRZI-Mark, 30 

NRZl-Space, 30, 44, 57 
NTAR, 83, 85, 87, 89, 94, 144 
NTBCR, 83, 87, 94, 144 

NV, 110, 121, 123, 138, 141 


Odd Address, 66, 73, 75 
Ones, 53, 115 
Consecutive, 44, 55, 78 
OnLoop, 53, 57, 130 
Opening Flag, 55, 77 
Opening Syne, 51, 52, 77 
Options 
DMA Cycles, 22-23, 101 
Interrupt 
DMA, 123 
Serial, 120-121 
Order (of programming), 125 


Overflow (RCC FIFO), 68 


Overrun, 64, 70, 115 
Oversampling, 41 


P3Mode, 38 
P4Mode, 38 
P7-OL/U, 36, 146 
P7-OMode, 36, 145 
Package Drawing, 5 
Parity, 41, 46, 48, 50, 51, 52, 56, 59-60, 115 
Mark, 60 
Space, 60 
Partial Character, 56 
Pause 
All Channels (command), 80, 94, 96 
This Channel (command), 80, 94, 96 
PCR, 36, 38, 145 
PE, see Abort/PE 
Phase Locked Loop, 51, 77 
Pins, 5-8, see also specific names, e.g., [AS 
Pipelined mode, 9, 83-85, 94, 96, 101, 104, 122 
Port 
Control Register, see PCR 
Pins, 36-37 
Status Register, see PSR 
PORT1-0/CLK1-0 pins, 8, 25, 36 
PORT2 pin, 8 
PORTS//RxTSA pin, 8, 36, 38 
PORT4//TxTSA pin, 8, 36, 38 
PORTS5//RxSYNC pin, 8, 36 
PORT6//FSYNC pin, 8, 36, 37-38 
PORT7//TxComplete pin, 8, 36 
Power pins, 8 
Preamble, 51, 52, 53, 55, 62, 63, 77 
Flags as, 77 
PreEmpt, 99, 138 
PreSent, 62, 77, 78, 156 
PreSent IA, 62, 118, 158 
Preset CRC, 160 
Primary (station), 57 
Priority (of DMA Channels), 99 
Programming, Order of, 125 
Promiscuous, 54 
Protocol, 44 
PSR, 37, 146 
- Pullup Resistor, 6 
Purge Rx FIFO (command), 65, 72, 75 
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Purge Tx FIFO (command), 65, 68, 72, 75, 99, 119 


QAbort, 57, 60, 64, 115, 152 
Queued Status Bits Flowchart, 67 


R,W1C, 127 
R,W1U, 127 
R/W pin, 6, 12-13, 27-24, 100, 102-103, 110, 115 
RALCnt, 104, 105, 137 
RAR, 79, 81, 83, 94, 147 
RBCR, 70, 79, 80, 81, 83, 94, 122, 147 
RCC, 65-68, 70, 72, 74, 81, 92, 99, 119 
FIFO, 67, 68, 70, 81, 92 
Logic Model, 67 
Underflow, 67 
Valid, 160 


RCCFAvail, 68, 130 
RCCFOvflo, 68, 130 
RCCR, 66, 68, 147 
RCCUnder IA, 67, 119, 153 
RCCUnder L/U, 67, 143 
RCHR, 67 
RCLR, 65, 67, 68, 70, 72, 74, 149 
RCmd, 38, 68, 71, 75, 116, 148 
RCSR, 38, 46, 47, 48, 50, 56, 57, 59, 60, 61, 62-64, 
68, 75, 78, 99, 115, 116, 148 
RD IE, 116, 120, 141 
RD IP, 52, 54, 55, 68, 73, 116, 120, 136 
RD IUS, 116, 120, 136 
RDIAR, 94, 122, 149 
RDMR, 79, 80, 83, 85, 87, 89, 90, 92, 93, 94, 95, 96, 
97, 104, 105, 122, 150 
RDR, 15, 16, 60, 61, 62, 70, 72, 74-75, 76, 149 
Read Strobe, see /RD pin 
Read/Write control, see R//W pin 
Ready, see /WAIT//RDY pin 
ReArbTime, 100, 138 
Receive 
Address Register, see RAR 
Byte Count Register, see RBCR 
Character Clock, 35 
Character Count Register, see RCCR 
Clock(s), 25-29, 30, see also RxCLK, /RxC pin 
Command/Status Register, see RCSR 
Count Limit Register, see RCLR 
Data, see RxD pin 


Receive (continued) 
Data Interrupt, 776 
Enable, see RD IE 
Pending, see RD IP 
Request Level, 116 
Under Service, see RD IUS 
Data Register, see RDR 
Datapath Logic Model, 59 
DMA 
Interrupt Arm Register, see RDIAR 
Mode Register, see RDMR 
Request, 7, 52, 54, 55, 68, 73, 78, see also 
/RxREQ pin 
Interrupt Control Register, see RICR 
Mode Register, see RMR 
Status Block, see RSB 
Status Interrupt, 115-116 
Enable, see RS IE 
Pending, see RS IP 
Service Routine (sample flowchart), 1177 
Under Service, see RS IUS 
Sync output, 8, 35 
Sync Register, see RSR 
Time Slot Assigner, 37-39 
Gate, 8, 38 
vs. Transmit DMA Indication, 5, 22, 101 
Reference Clock(s), 8, 27, 36 
RegAddr, 15, 126, 129, 137 
Register(s), see specific register names, e.g., CCAR 
Addressing, 15-19, 74, 126 
Reading and Writing, 21-24 
Request Level 
DMA, 73, 75, 79, 97, 99 
Interrupt, 73, 75, 116, 118 
Request Threshold, see Request Level 
Request(s) 
DMA, 97-99 
Interrupt, see /INT pin 
Reset, 5, 32, 36, 125 
All Channels (command), 80, 93, 94, 96 
Highest DMA IUS (command), 96, 122 
Highest Serial |US (command), 72, 120 
Software, 74 
This Channel (command), 80, 93, 94, 96 


Residual Frame Length, 56-57 
Resynchronization, 44 

RICR, 37, 38, 60, 61, 63, 64, 73, 75, 99, 116, 157 
Ring (of Buffers), 89 

Rising Edges, 119 


RMR, 29, 33, 45, 49, 51, 53, 55, 56, 57, 58, 59, 60, 
64, 71,115, 152 


RO, 127 

ROC, 127 

Rotating Priority, 107 

RS IE, 120, 141 

RS IP, 61, 115, 116, 120, 136 

RS IUS, 120, 136 

RSB, 50, 52, 56, 57, 59, 60, 61, 63, 64, 65, 67, 69-70, 
69, 78, 81, 85, 87, 89, 92-93, 99 

Using for 1553B, 70 

RSBinA/L, 85, 89, 92, 93, 98, 105, 150 

RSR, 51, 54, 55, 73, 152 

RTCmd, 20, 27, 54, 56, 64, 65, 68, 71, 75, 78, 79, 97, 
99, 120, 129 


RTMode, 32, 129 
RTReset, 74, 75, 129 
RTSACount, 37, 39, 151 
RTSAOffset, 37, 39, 151 
RTSASlot, 37, 39, 151 
RW, 127 

Rx/Tx Cmd, 137 

Rx/Tx Reg, 15, 137 
RxAvail, 64, 148 


RxBound, 48, 49, 50, 52, 54, 55, 56, 57, 59, 60, 61, 
63, 64, 68, 69, 70, 78, 81, 85, 89, 93, 99, 116, 148 


RxBound IA, 64, 115, 151 

RxCDn IA, 35, 119, 153 

RxCL/U, 35, 143 

RxCLK, 25-29, 33, 34, 37-38, 47, 50, 54, 63 

RxCLKSre, 28, 135 

RxCMode, 35, 140 

RxCRCEnab, 58, 59, 152 

RxCRCStart, 58, 71, 152 

RxCRCType, 58, 59, 152 

RxCUp IA, 35, 119, 153 

RxD pin, 7, 25, 27, 28, 29, 31-32, 33, 45, 46, 50, 54, 
59, 63, 76 

RxDecode, 29, 46, 152 

RxDMA IE, 138 

RxDMA IP, 134, 153 

RxDMA IUS, 134, 153 

RxEnable, 33, 45, 152 


RxFIFO, 10, 47, 48, 50, 51, 52, 54, 56, 59, 60, 61, 62, 
64, 65, 67, 68, 69, 70, 72, 73, 74-75, 76, 79, 81, 83, 
93, 97, 99, 104, 115, 116, 148 


RxLength, 45, 49, 51, 55, 56, 59, 60, 152 
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RxMode, 33, 46, 47, 48, 50, 51, 52, 53, 54, 57, 132- 
134 


RxOver, 60, 61, 64, 70, 116, 148 
RxOver IA, 64, 115, 151 
RxParEnab, 60, 64, 152 
RxParType, 60, 64, 152 

RxRDn IA, 36, 119, 153 
RxResidue, 46, 56, 148 
RxRL/U, 36, 143 

RxRMode, 35, 140 

RxRUp IA, 36, 119, 153 
RxStatBlk, 69, 70, 131 


RxSubMode, 44, 47, 49, 51, 52, 54, 55, 56, 63, 132- 


134 
RxSYNC, see Receive Sync output 


S//D pin, 5, 11, 14, 16, 21-24, 100, 101, 138 

SAbort, 94, 96, 122, 150, 157 

SAbort IA, 149 

SDIR, 110, 122, 153 

SDLC, 43, see also HDLC/SDLC 
Loop, see HDLC/SDLC Loop 

Second Byte Exception, see 2ndBE 

Select 
D15-8 First (command), 14, 20, 66, 72, 74, 80 
D7-0 First (command), 14, 20, 66, 72, 74, 80 
RICRHi=/INT Level (commana), 73, 116 
RICRHi=/RxREQ Level (command), 73, 99 
RICRHi=FIFO Status (command), 73, 75 
RICRHi=RTSA Data (command), 38, 73 
Serial Data LSB First (command), 73 
Serial Data MSB First (command), 54, 56, 73 
Straight/Swapped Memory Data, 160 
TICRHi=/INT Level (command), 73, 118 
TICRHi=/TXREQ Level (command), 73, 97, 99 
TICRHi=FIFO Status (command), 73, 75 
TICRHi=TTSA Data (command), 38, 73 

Send Abort (command), 55, 73 

Send Frame/Message (command), 73, 74, 76, 78 

SepAd, 14, 16, 128 

Separate Address, 14 

Serial 
/DMA, see S//D pin 
Bus, 31, 32 
vs. Array/List Cycles, 5 

Set DMA Interrupt Register, see SDIR 

Set EOF/EOM (command), 71, 73, 76 


Shared Zeroes (between Flags), 55, 58, 78 
Shaved (Stop bits), 28, 77 
Shift Register, 59 
ShortF/CVType, 50, 56, 60, 61, 63, 70, 148 
SICR, 27, 33, 35, 36, 67, 179, 120, 153 
Single 
Buffer mode, 8, 81-83, 94, 122 
Cycle (BRG), 27, 72 
Flag, 77, 78 
Pulse (interrupts), 110, 113 
Slave Cycles, 6 
Slaved Monosync, 53, 58, 133 
Software 
Requirements, Interrupt Service Routines, 110 
Reset, 74 
Source Address (Ethernet), 54 
Sources (of Interrupts), 108 
DMA, 122 
Serial, 115-120 
Space, 42, 47, 53, 76 
Parity, 60 
Square Wave, 51 
SRightA, 15, 128 
Start 
(commands), 94, 97 
/Continue All Channels (command), 96 
/Continue This Channel (command), 83, 94, 96 
[Init All Channels (commana), 96 
[nit This Channel (commana), 85, 87, 94, 96, 97 
All Channels (command), 96 
Bit(s), 41, 46, 53, 54, 72, 77 
Sequence(s), 48, 50 
This Channel (commana), 81, 83, 94, 96 
Status Interrupt Control Register, see SICR 
Status Interrupts, see Receive and Transmit Status 
Interrupts, a/so Miscellaneous Interrupts 
Status Reporting, 60-64 
Stop Bit(s), 41, 46, 47, 49, 63, 64 
Shaved, 28, 77 
Stopping the Clocks, 28-29 
Storing RSBs, 92-93 
Strip (Sync), 51 
Strobe 
Address, see /AS pin 
Upper, see /UAS pin 
Data, see /DS pin 
Read, see /RD pin 
Upper Address, see /UAS pin 
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Strobe (continue) 
Write, see /WR pin 
Supervisory (station), 57 
SYN, 52 
SYN-SYN, 52 
SYNO, 51 
SYN1, 51 
Sync 
Character(s), 42, 50-53, 58, 62, 63, 65-67, 72, 
115, 118 
Closing, 76 
Idle, 76 
Opening, 77 
Frame, 36, 37 
Input, 33, 43, 50 
Output, 8, 35 


Synchronizing Frames/Messages with Software 
Response, 78 


Synchronous, 78, 50, 59 
Clocking, 28 


Table of Contents, 2-4 

TALCnt, 104, 105, 137 

TAR, 79, 81, 83, 94, 155 

TBCR, 66, 79, 80, 81, 83, 94, 122, 155 

TCOR, 27, 72, 154 

TCORSel, 27, 151 

TC1R, 27, 72, 154 

TC1RSel, 27, 158 

TCB, 50, 56, 65, 67, 68-69, 72, 74, 87, 90-92, 91, 97 
Using for 1553B, 70 . 

TCBinA/L, 85, 87, 89, 90, 92, 98, 105, 157 

TCC, 51, 58, 65-68, 72, 74, 76, 80, 81, 90, 92 
Logic Model, 66 

TCCR, 66, 69, 155 

TCLR, 65, 69, 72, 74, 156 

TCmd, 38, 55, 71, 75, 76, 78, 118, 156 


TCSR, 29, 38, 45, 51, 53, 55, 56, 57, 58, 62, 73, 75, 
76, 77, 78, 99, 118, 156 


TD IE, 118, 119, 120, 141 

TD IP, 73, 118, 119, 120, 136 
TD JUS, 119, 120, 136 
TDIAR, 94, 122, 157 


TDMR, 79, 80, 83, 85, 87, 89, 90, 93, 94, 95, 96, 97, 
104, 105, 122, 157 


TDR, 15, 16, 66, 68, 71, 72, 73, 74-75, 76, 157 
TermE, 80, 85, 87, 92, 93, 150, 157 
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Test Mode, 10 
Control Register, see TMCR 
Data Register, see TMDR 
Threshold (Request), see Level 
TICR, 38, 62, 73, 75, 76, 77, 78, 99, 178, 158 
Time 
Constant 0 Register, see TCOR 
Constant 1 Register, see TC1R 
Slot Assigners, 8, 37-39 
Gate outputs, 36 
Timing 
Bus Acquisition, 100-101 
Bus Release, 100-107 
Interrupt Acknowledge, 111-114 
Master Read Cycles, 102 
Master Write Cycles, 103 
Parameters, 10 
Reference (DMA/Bus), 5 
Register Access, 23-24 
TMCR, 10, 153 
TMDR, 10, 754 
TMR, 29, 34, 45, 51, 53, 57, 58, 59, 71, 76, 77, 78, 
159 
Transfer(s), Max per Bus Grant, 128 
Transitions, 31 
Transmit 
Address Register, see TAR 
Byte Count Register, see TBCR 
Character 
Clock, 35 
Count Register, see TCCR 
Counter, see TCC 
Clock(s), 25-29, 30, see also TxCLK, /TxC pin 
Command/Status Register, see TCSR 
Complete, 8, see Tx Complete 
Control Block, see TCB 
Count Limit Register, see TCLR 
Data, see TxD pin 
Data Interrupt, 118 
Enable, see TD IE 
Pending, see TD IP 
Request Level, 118 
Under Service, see TD IUS 
Data Register, see TDR 
DMA 
Byte Ordering, 14 
Interrupt Arm Register, see TDIAR 
Mode Register, see TDMR 
Request, 7, 67, 68, 73, see also /TXREQ pin 
Interrupt Control Register, see TICR 
Mode Register, see TMR 


Transmit (continued) 

Status Block, see TCB 

Status Interrupt, 116-118 
Enable, see TS IE 
Pending, see TS IP 
Under Service, see TS IUS 

Sync Register, see TSR 

Time Slot Assigner, 37-39 
Gate, 8, 38 


Transparency, 43, 52 


Transparent Bisync, 33, 52, 58, 59, 63, 64, 68, 69, 70, 
72, 81,99, 115, 133 


Trigger 
Channel Load DMA (commana), 74, 126 
Rx DMA (command), 65, 74, 78, 79, 99 
Tx DMA (command), 65, 68, 74, 78, 97 

TS IE, 120, 141 

TS IP, 118, 120, 136 

TS IUS, 120, 136 

TSR, 51, 53, 73, 159 

TTSACount, 38, 39, 158 

TTSAOffset, 38, 39, 158 

TTSASlot, 38, 39, 158 

Two Pulse Mode, 14, 114 

Tx Complete, 35, 36, 53 

TxCDn IA, 35, 119, 153 

TxCL/U, 35, 143 

TxCLK, 25-29, 34, 37-38, 47 

TxCLKSre, 28, 135 

TxCMode, 35, 140 

TxCRCatEnd, 51, 58, 76, 78, 159 

TxCRCEnab, 58, 159 

TxCRCStart, 58, 71, 159 

TxCRCType, 58, 159 

TxCtriBlk, 65, 68, 70, 72, 74, 92, 131 

TxCUp IA, 35, 119, 153 


TxD pin, 7, 8, 25, 28, 30, 31-32, 34, 45, 46, 47, 51, 57, 
62, 76 


TxDMA IE, 138 

TxDMA IP, 134, 153 

TXDMA IUS, 134, 153 
TxDMode, 32, 45, 47, 140 
TxEmpty, 62, 125, 156 
TxEnable, 34, 45, 159 
TxEncode, 29, 45, 46, 77, 159 


TxFIFO, 8, 48, 50, 52, 53, 55, 57, 58, 59, 62, 65, 67, 
68, 72, 73, 74-75, 76, 77, 78, 81, 97, 104, 118, 119 


Txidle, 45, 51, 53, 55, 57, 62, 73, 76, 77, 78, 118, 156 
TxLength, 45, 49, 51, 56, 60, 159 


TxMode, 46, 47, 48, 51, 52, 53, 54, 57, 58, 76, 77, 
118, 1382-134 


TxParEnab, 56, 59, 159 
TxParType, 60, 159 

TxPreL, 53, 55, 62, 77, 131 
TxPrePat, 53, 55, 62, 77, 131 
TxRDn IA, 36, 119, 153 
TxResidue, 56, 69, 130 
TXRL/U, 36, 143 

TxRMode, 35, 140 

TxRUp IA, 36, 119, 153 
TxShaveL, 28, 46, 131 


TxSubMode, 28, 44, 46, 47, 48, 49, 51, 52, 54, 55, 57, 
59, 69, 70, 73, 76, 77, 1382-134 


TxUnder, 29, 62, 156 
TxUnder IA, 62, 118, 158 
TypeCode, 121, 123, 139, 142 


Types (of Interrupts), 108 
DMA, 121 
Serial, 115-120 


U//L, 14, 15, 129, 137 

UASAII, 23, 101, 104, 138 

Underflow (RCC), 67 

Underrun, 9, 51, 52, 53, 54, 55, 57, 58, 59, 76 
Unlatch, 116, 120 

Upper Address Strobe, see /UAS pin 


Vcc pins, 8 

Vector, see Interrupt Vector 
Vector Includes Status, see VIS 
VIS, 110, 121, 123, 138, 141 
Vss pins, 8 


Wait, see /WAIT//RDY pin 
Insertion, 22, 101, 138 
Wait2Send, 73, 74, 76, 77, 78, 158 
Wait4RxTrig, 74, 78, 79, 99, 131 
Wait4TxTrig, 73, 74, 78, 131 
WO, 127 
WOC, 127 
Word(s), 46, 48 
Command/Status, 63, 70 
Data, 63, 70 


WordStatus, 60, 61, 151 


Write 
Strobe, see /WR pin 


X.21, 53 


2380, 72 
Z80, 79, 97 
Z8000, 72, 75, 79, 97 
Zero Byte Count, 79, 87, 89, 90, 94 
Zeroes 
Inserted, 55, 56 
Shared, 58, 78 
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